This post is more than 5 years old
3 Posts
0
70078
November 10th, 2015 15:00
N3048P voice vlan and DHCP issues
Hello,
I just received several N3048P switches for our access layer and 2x 4048-ON for our core layer. The N3048P's are VLT'd between the two 4048's. There are 4x N3048P's stacked together. The 4048's own all the gateways via VRRP.
I have 802.1x working with my test Windows client, and I can get the phone (Cisco 7941) to acquire a DHCP address if I put it on a "switchport mode access" port. However, if I change the port to a general port with voice vlan enabled and 802.1x, the phone does not get a DHCP address, but the PC attached to the phone still gets a DHCP address in the correct VLAN.
I see CDP and LLDP messages being exchanged via Wireshark, and it looks like the phone and the switch are exchanging the Voice VLAN correctly.
My question is, why can the phone not get a DHCP address?
Here is the relevant config from the switch below. I realize some of the config may be duplicate for troubleshooting measures:
vlan 75
name "Test"
exit
vlan 76
name "Test_Phones"
exit
ip helper-address 1.1.1.3 dhcp
ip helper-address 1.1.1.4 dhcp
interface vlan 75
ip address 172.16.75.4 255.255.255.0
ip helper-address 1.1.1.3
ip helper-address 1.1.1.4
exit
interface vlan 76
ip address 172.16.76.4 255.255.255.0
ip helper-address 1.1.1.3
ip helper-address 1.1.1.4
aaa authentication login "defaultList" local
aaa accounting dot1x default start-stop radius
dot1x system-auth-control
aaa authentication dot1x default radius
aaa authorization network default radius
voice vlan
radius-server source-ip 172.16.75.4
radius-server key "key"
radius-server host auth 1.1.1.1
primary
name "rad1"
usage 802.1x
key "key"
exit
radius-server host auth 1.1.1.2
name "rad2"
usage 802.1x
key "key"
exit
radius-server host acct 1.1.1.1
name "rad1"
exit
radius-server host acct 1.1.1.2
name "rad2"
exit
interface Gi2/0/1
description "802.1x client port"
spanning-tree portfast
spanning-tree guard root
switchport mode general
switchport general allowed vlan add 75-76 tagged
dot1x reauthentication
dot1x timeout quiet-period 5
dot1x timeout tx-period 5
dot1x guest-vlan 20
dot1x unauth-vlan 20
lldp transmit-tlv sys-desc sys-cap
lldp transmit-mgmt
lldp notification
lldp med confignotification
voice vlan 76
voice vlan auth disable
exit
Thank you for any input you may have. Let me know if there is any other information I can provide.
-Jason
jhurlbert
3 Posts
2
November 16th, 2015 15:00
This ended up being the correct port configuration:
interface Gi2/0/1
description "802.1x client port"
spanning-tree portfast
switchport mode general
switchport general pvid 75
switchport general allowed vlan add 75
switchport general allowed vlan add 76 tagged
dot1x port-control mac-based
dot1x reauthentication
dot1x timeout quiet-period 5
dot1x timeout supp-timeout 15
dot1x timeout tx-period 5
dot1x timeout guest-vlan-period 15
dot1x guest-vlan 20
dot1x unauth-vlan 20
voice vlan 76
voice vlan auth disable
The most important line here is the "dot1x port-control mac-based". I had "dot1x port-control auto" configured, but that does not work as expected. Also, setting the guest-vlan-period and supp-timeout were necessary. If the port was downed, the switch wouldn't necessarily reauth the port.
DELL-Josh Cr
Moderator
•
9.6K Posts
•
42.5K Points
0
November 11th, 2015 10:00
Hi,
How is the general port configured? Did you change the PVID to be the untagged VLAN? Are the phone and client on separate VLANs and do the phones tag their VLAN? If it is working in access mode, it sounds like it works when the VLANs are not tagged.
jhurlbert
3 Posts
0
November 13th, 2015 07:00
Hi Josh,
1. I have the general mode port configured in my example above.
2. I've tried specifying "switchport general pvid 76", but the phone still doesn't receive a DHCP address (although, it gets VLAN 76 assigned to it via LLDP, I can confirm on the phone itself).
3. The phone and the client are on separate VLANs as shown in my example above (75 for client, 76 for phones). The client authenticates correctly with 802.1x correctly, and gets put into VLAN 75 as it should.
I have been on the phone with support the last two days now, and we haven't found a solution yet. When we figure it out, I will post back here.
-Jason