04-27-2009 06:55 PM - edited 03-06-2019 05:25 AM
Hi:
I have a switch that has a data vlan configured and a voice vlan.
data vlan is 341
voice vlan is 546
Here is the config:
==================================================================================
vlan 546
name Avaya_Phone_vlan546
vlan 341
name data_vlan
vlan access-map VOICE 10
action forward
match ip address Avaya_Phones
vlan access-map VOICE 20
action forward
match ip address NETWORK_SERVICES
vlan filter VOICE vlan-list 546
vlan 546
name Avaya_Phone_vlan546
ip access-list extended Avaya_Phones
remark ACL for Avaya traffic
permit udp any range 10000 14001 any range 10000 14001
permit tcp any range 1024 65535 any range 61440 61444
permit udp any range 10000 14001 any eq 5005
permit udp any range 1024 65535 any eq 1719
permit udp any eq 1719 any range 1024 65535
permit tcp any range 1024 65525 any range 1719 1720
permit tcp any range 1719 1720 any range 1024 65525
permit udp any eq 68 any eq 67
permit udp any range 1024 5000 any eq 53
permit tcp any range 1024 5000 any eq 411
permit tcp any range 1024 5000 any eq 80
permit tcp any range 1024 5000 any eq 443
permit tcp any any eq 80
permit tcp any any eq 81
permit udp any any eq 161
permit udp any range 1024 5000 any eq 514
permit tcp any range 1024 5000 any eq 50002
permit udp any any eq 50000
permit udp any any eq 69
permit icmp any any
ip access-list extended NETWORK_SERVICES
remark PIM/HSRP/DHCP
permit pim any any
permit tcp any 10.76.160.0 0.0.31.255 eq 22
permit tcp any 10.76.192.0 0.0.31.255 eq 22
permit tcp any 10.76.160.0 0.0.31.255 eq 21874
permit tcp any 10.76.192.0 0.0.31.255 eq 21874
permit tcp 10.76.160.0 0.0.31.255 eq 22 any
permit tcp 10.76.192.0 0.0.31.255 eq 22 any
permit tcp 10.76.160.0 0.0.31.255 eq 21874 any
permit tcp 10.76.192.0 0.0.31.255 eq 21874 any
permit tcp host 10.76.171.1 any eq smtp
permit tcp host 10.76.179.1 any eq smtp
permit tcp host 10.76.171.1 any eq domain
permit tcp host 10.76.179.1 any eq domain
permit udp host 10.76.179.1 any range 1024 65525
permit udp host 10.76.171.1 any range 1024 65525
permit udp any range 1024 65525 host 10.76.179.1
permit udp any range 1024 65525 host 10.76.171.1
permit udp any eq 1985 any eq 1985
permit udp any eq bootps any eq bootpc
permit udp any eq bootps any eq bootps
permit udp any eq domain any
permit tcp any eq www any
permit icmp any 10.76.160.0 0.0.31.255 echo
permit icmp any 10.76.160.0 0.0.31.255 echo-reply
permit icmp any 10.76.192.0 0.0.31.255 echo
permit icmp any 10.76.192.0 0.0.31.255 echo-reply
permit icmp 10.76.160.0 0.0.31.255 any echo
permit icmp 10.76.160.0 0.0.31.255 any echo-reply
permit icmp 10.76.192.0 0.0.31.255 any echo
permit icmp 10.76.192.0 0.0.31.255 any echo-reply
permit icmp any any ttl-exceeded
deny ip any any log
interface vlan546
ip address 10.76.185.251 255.255.254.0
ip helper-address 10.76.171.1
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-dense-mode
service-policy input user-marking
no shut
!
==================================================================================
What I dont understand is that the vlan filter (vlan access map) is applied to the Avaya phone vlan, yet the traffic its filtering is the kind of traffic that would be generated by a PC, not a phone, like http or https. Why is that?
The PC would indeed be connected to the phone and the phone to the switch. The PC would be on the data vlan and the phone on the voice, of course. So, shouldnt the vlan access map be applied to the data vlan?
Solved! Go to Solution.
04-28-2009 12:29 PM
04-28-2009 03:31 AM
Hello Joe,
I share your doubts.
How are configured the switch ports ?
I think this can help to understand if this config is correct or not.
Hope to help
Giuseppe
04-28-2009 05:05 AM
Giuseppe, my good man! We meet once again...:-)
Here is the entire switch config attached.
Take note that there are a lot of negation commands (no). It's just wiping out part of the old config...you know.
Its pretty straightforward. A voice vlan, data vlan, both configured under the switchports and some QoS.
Thanks
04-28-2009 07:04 AM
Hello Joe,
the VACL should be divided in two different VACLs one applied to voice vlan and one applied to data vlan.
the ports have
switchport access vlan 341
switchport voice vlan 546
so only traffic for the VoIP phones should be seen by SVI Vlan546.
Hope to help
Giuseppe
04-28-2009 10:09 AM
Giuseppe:
Sorry, but you totally lost me.
I am asking why the vacl was applied to the voice vlan when it seems as though the traffic in the access lists that it matches is the kind of traffic that is generated by a PC, not a phone. For example, http and https.
Also, the SVI for that vlan is just for management purposes. This is a L2 switch.
Can you please clarify what you mean?
Thanks
04-28-2009 10:14 AM
Hello Joe,
I'm probably lost myself ...
However, I meant
this part should be fine:
vlan access-map VOICE 10
action forward
match ip address Avaya_Phones
the second block instead shouldn't match
so the idea is to have the second block associated to a second VACL (different name) that then is applied to the data vlan.
And then yes the VACL is applied to the L2 vlan object and can filter between L2 ports, to an SVI we can apply the normal ACLs like we do in routers sorry for the confusion.
The following link to C3750 config guide can help
Hope to help
Giuseppe
04-28-2009 10:46 AM
Can you give us a background on this config?
I noticed the no on some of the commands which imply those commands are currently in the config, correct?
I also noticed each switchport has 2 different voice vlan. One prepended with the no and another that looks to be a new implementation.
If the voice vlan denoted under the switchport is/was 92, then the vlan-map did nothing and it will affected the new voice-vlan implementation in term of traffic.
With that said, you are right. Whoever tried to implement the vlan-map, had in mind to apply it under the data vlan but using VOICE as the reference, it confuses the real meaning of it.
HTH,
__
Edison.
04-28-2009 11:04 AM
Hi, Edison:
Hope youre doing well today. Thanks for your time.
This config is not somethign I generated. You are right in that there are plenty of negation commands meant to wipe out earlier config lines.
Nonetheless, each switchport should have a data vlan, 341, and a voice vlan, 545, configured in a typical MVAP setup.
This is what each switchport will look like:
interface GigabitEthernet1/0/17
switchport access vlan 341
spanning-tree portfast
switchport voice vlan 546
ip arp inspection limit rate 100
priority-queue out
mls qos vlan-based
ip dhcp snooping limit rate 100
Pretty straightforward.
My questions are:
1.) Why is the VACL, whose matching access lists seem to target the kind of traffic that a PC would send, not an IP Phone, be applied to the voice vlan? Its not just a name thing, it is actually applied to the voice vlan. Seems weird.
2.) These are Avaya phones that will be connected to these switchports. Since that is the case, shouldnt the switchports be configured as trunk ports and not MAVP ports? I say this because it is my understanding that IP Phones that use voice vlans (auxilliary vlans) exchange CDP information with the switch. The switch, through CDP, informs the IP Phone what the voice vlan ID is (VVID), and instructs it on how to encapsulate the packet - either dot1q, dot1p, orf untagged. If the Avaya phone does not support dynamic discovery, the voice vlan will also not be enabled.
3.) Assuming that #2 is correct and a trunk port IS indeed configured, how is the non-Cisco phone discovered? It would still have the same problem as it did with the voice vlan - no CDP support. So, how does it know what vlan it should be in?
Should the native vlan be set on these trunk ports?
From a typical, but separate, config I have in front of me, the ports are trunk ports and they assign the native vlan to the data vlan. So, the PC traffic is untagged as it rides the dot1q trunk between the IP Phone and the switch, and the voice traffic will _ I ASSUME -- be tagged with the voice vlan tag identifier. If so, once again, how does the IP Phone know what VVID it should use, when it does not support CDP discovery? Is there a way of manually configuring the Avaya phones and placing them in a vlan?
Thanks
04-28-2009 11:12 AM
Doing well, thanks for asking :)
1) I can't answer this one. The only one can answer this one is the Engineer who initially implemented this. Perhaps he had a reason at the time, perhaps not. Based on the information provided, there isn't a reason for the VACL. After years of experience, you will come to realize some configs don't make sense and wasting time finding out why, can be unproductive :)
2) That's not the case. Avaya and Nortels do support the aux voice vlan on cisco switchport configs. You can use the trunk design, but it's no longer necessary. The voice vlan information is obtained from the TFTP server during the phone initial boot. It tells the phone to use the voice vlan x for voice traffic. Different manufacturers use a different DHCP string for such feature.
3)
See answer above
4) The information is not provided via CDP. The information is provided via TFTP during the initial phone boot process.
HTH,
__
Edison.
04-28-2009 11:39 AM
OK, now we are getting somewhere. :-)
1.) I agree. I wont try to figure him out anymore. I just wanted an experienced set of eyes to look at the config and at least validate my concern and let me know that I am not missing something obvious.
2.) Here is where I would liek to drill a little deeper, if you are so inclined. It seems like we have a chicken and egg scenario. You are telling me that the phone learns of its vlan assignment through the TFTP server, but the IP Phone must broadcast a DHCPDiscover first to get the TFTP server address via DHCP option 150. So, on which vlan is that DHCP request broadcast? The phone doesnt know what vlan it belongs to, so how does it tag the packet?
Lastly, obtaining the VVID from the tftp server only applies to non-Cisco phones, right? I read in several documents that Cisco phones do rely on CDP.
Thanks
04-28-2009 11:49 AM
The phones always boot up on the data vlan, regardless of the switchport setting trunk|voice.
That's the main reason when implementing switchport port-security, you must have 2 MAC addresses allowed in the data vlan because the phone will use one during the initial process.
So, in recap, the phone boots twice. The initial bootup, the phone looks for a DHCP server, this DHCP server provides the IP address in addition to the string value. This string value contains the TFTP server information and the phone then reboots again. It downloads the TFTP information which contain the VVID assignment.
Cisco phones also rely on the same process and it uses CDP for power conservation. There is also LLDP for 3rd party IP Phone providers. LLDP support is available in selected IOS releases and hardware.
Edit: After reading my own statement, the phone will reboot once again after getting the VVID info from TFTP - so I'm correcting myself. It reboots 3 times.
HTH,
__
Edison.
04-28-2009 12:12 PM
Edison, you're a scholar and a gentleman. :-)
Is there documentation from Cisco that elaborates on the mechanics and the fine details of the logic of VoIP configuration? I wouldnt have bothered anyone with this had I been able to find a good informative document.
Can you recommend one?
Thanks!
04-28-2009 12:29 PM
04-30-2009 10:41 AM
Edison:
Just a quick update for you.
I just spoke to the engineer who configured the devices and now I got some questions answered:
1.) The VACL that is applied to the VOICE vlan includes access-lists that target what seem like PC traffic -- like hhtp, https, etc -- because the IP Phones use http to download configuration information from a centralized server. It uses TFTP, too, which is the standard.
Also, the seemingly arbitrary port ranges -- 1024 to 5000 -- are a result of sniffing Avaya phone traffic and just observing what source ports it likes to grab when it boots up or has to communicate with the ttp server.
2.) The famous "pseudo routed" connection issue from yesterday. lol
All IP phones default to the 6513 only, the reason the 4510 has an SVI on it is just...are you ready for this?...for "troubleshooting purposes," according to the demands of the client. What that means, he doesnt really know, but he didnt want to argue with them. So, he also recognizes that it serves no earthly purpose in forwarding traffic. There is also nothing planned for an HSRP application.
Well, thats it...
After all the help you and Giuseppe gave me, I figured I at least owed you an update to clarify things.
Ciao
04-30-2009 10:47 AM
Thanks for the update. It definitely helps understand the reasoning behind the config design.
__
Edison.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: