All routing is done by the MSFC2 on the Sup2. Here's some specific's

VLAN #, interfaceIP/subnet

VLAN 53, 10.5.3.1/24

VLAN 210, 10.20.10.1/24

VLAN 250, 10.20.50.1/24

The DHCP server is on VLAN210

The Phone System/BOOT server is on VLAN53

Workstations are on VLAN250

The setup that works is if a switch port has NO auxiliaryvlan specified.  the native VLAN can be 250 or 53.  In either case, the phone pulls an IP for the defined native VLAN (agian, I've tested it with native VLAn of 250 or 53), contacts the boot server and pulls it's config files and registered with the VoIP server.

When things go wrong is if I add an auxiliaryvlan.  So the setup would ne native vlan 250, auxiiliaryvlan 53.  With the switch port defined this way, the phone pulls an IP of 10.5.3.100 and the desktop connected through the phone pulls an IP of 10.20.50.100.  So, CDP is working appropriately to get the phone on the VLAN it needs to be on, and to pull an IP on that VLAN.  The phone is reachable on the network, but a communication problem is now occuring between the phoen and the boot server.  Both devices are on the same VLAN at this point.

There are no security configs on the ports, but there is QoS defined by using "autoqos trust cos".

I used the same settings (VLAN Numbers, interface IP's, and QoS, native and voice vlan definitions) when I was previously using 3560's with IOS on them and the same exact phones, worked fine.  Likewise, I was using this same 6513 and same version of CatOS a few years ago, with the same vlan numbers, QoS, native/auxiliaryvlan settings, and it worked back then.  The only change is the software on the phone.  Unfortunately, I don't really have any way to invoke Polycom support to assist.

Hi pfc

thanks for the info.. it looks a bit strange though.. Just to troubleshoot, can you see by connecting other models of ip phones to this port, instead of plugging a polycom ? Does your call manager show any log or errors when the polycom tries to download the config files ? am sure looking at the boot server errors, we can troubleshoot something here... also did u try to configure a port directly on vlan 53 and try accessing the boot server ?

now since you already get an ip address for the phone, i really donno if we need to look more on layer 2 technologies like cdp, l2 qos, aux vlan etc... can you span this port, and run a sniffer of it to see what exactly happens ?

Raj

Not actually running a CallManager, but another product (Interactive Intellgience EIC).  The boot server is an embedded HTTP server with the EIC server.  There is logs I can look at though.  If I recall correctly, when I troubleshot this originally, the boot server wasn't even seeing a request for files from the phone.

Only phones in use that would even use the boot server are Polycom phones.  A Cisco phone can work with my system, but I have to configure those using a 3rd party TFTP/FTP server, so it's not a useful troubleshooting step.

I did set a port to native vlan of 53 with no auxiliaryvlan.  The phone contacts the boot server fine in this configuration, which makes it seem more like L2 problem.

I can do a new port span dn sniff with wireshark.  I did that this morning but didn't save the info. There was very little information from my phones IP to other IP's.  As I recall, it requested an IP, and then it made an NTP request to get updated time, and then there was absolutely nothing until the phone timedout on it's boot server request and defaulted to the last known config saved in the phone.

"when I troubleshot this originally, the boot server wasn't even seeing a request for files from the phone" - are you sure of the dhcp settings on pointing to the correct boot server on the auxillary vlan ?

Is it possible for you to hardcode the bootserver settings for the polycom on the aux vlan , instead of having DHCP give these parameters ?

Raj

Hard coding the boot server doesn't make any difference.

I guess I'm going to upgrade to 8.6(4) this weekend.  That's the last version of CatOS put out for Sup2's.  Maybe there's a bug causing the problem that is only now present due to new firmware on the phones.

Ya.. thats a good idea.. but have a look at the release notes of 8.6 to make sure there are any mocre bugs.. as of your ios version, we didnt see much on the release notes right ? 

Upgrade your switch and let us know the results.. all the best..

Raj

something that may or may not be useful in me figuring this out.

I did packet captures with no auxiliaryvlan set and with.  I'm trying to compare entry-by-entry what is differnet.  I noticed that there is unanswered ARP brodcast traffic when the phone is on an auxiliaryvlan.

The request is from the phone and it says "who has 10.5.3.10?  tell 10.5.3.101".

10.5.3.10 = boot server/phone system

10.5.3.101 = IP of phone

This request repeats over and over again.  I also a request "who has 10.5.3.1? tell 10.5.3.101", which does get answered by the switch.  The answer from the switch is the mac of the switch, as the 10.5.3.1 is the vlan interface IP for this vlan.

when no auxiliaryvlan is set, there is still some ARP broadcast traffic, bu tit's different.  I see:

"who has 10.20.50.1?  tell 10.20.50.103"

10.20.50.1 = vlan interface IP on switch

10.20.50.103 = IP of phone

this request is answered by the switch, and the answer is the mac of switch once again.

Does this indicate something useful to troubleshoot with?

Hi PFC

the sniffer traces looks to show what it is supposed to.. with aux vlan set, it basically points to the same VLAN as the EIC boot server, and hence the ARP request directly gets the IP address of the server (10.5.3.10) since the phone and the server are in the same LAN...

with aux vlan not set, the phone takes the data vlan , and the ARP tries going to the next hop (which is the VLAN Layer 3 IP address - 10.20.50.1)...

Did you still find the errors that you see on the EIC server when the phone is connected on auxillary vlan ? Is there any requirement for the phone to be on the aux vlan similar to where the boot server is ? Can you try setting the auxillary vlan to some other vlan (say create a new vlan 500) and have it routed across to the boot server? Just to check if it is a problem with aux vlan commands, or the real boot server ?

1) create vlan 500 (say 172.16.3.0/24)

2) Configure ip helper or commands to enable DHCP for the ip phone..

3) configure layer 3 forwarding on the switch to communicate with the boot server...

4) check connectivity

Let us know..

Raj

The problem occurs ONLY when I define auxiliaryvlan on the switch.  If auxiliaryvlan is NONE, I can put the port on ANY VLAN (including 53, where the server is), and everything is fine.

As you suggested, I created an entirely nerw VLAN on a different network (10.1.3.0/24) and assigned the auxiliaryvlan to this VLAN.  Same results as when I used VLAN 53.

Just as a quick comment  When you refer to layer 3 forwarding..  This is all handled by the MSFC2 on the Sup2, which has ip routing enabled.  I am not using anything like EIGRP or OSPF however (I did have eigrp active earlier when trying to troubleshoot this problem).  All the VLAN's are defined on the MSFC2 and the VLAN's on the Sup2 match.

EIGRP or OSPF should not be an issue here.. phones work good on layer 3, if the aux vlan isnt set.. and on layer 3 the msfc will forward the packets directly based on the destination ip address..

I just have one query.. what is the aux vlan settings you have configured on the port ? Can you copy paste the "set port auxilary vlan" configuration ? you can optionally enable cdpverify after defining the aux vlan..

set port auxiliaryvlan mod[/port] {vlan | untagged | dot1p | none} [cdpverify {enable | disable}]

try forcefully enabling the cdpverify, since the phones work on sending the info through CDP..

let us know

Raj

set port auxiliaryvlan 13/3 53

with "cdpverify enable", the switch never sets the auxiliaryvlan to active with the phone plugged in, so I have to set cdpverify disable.   This is the only way the phone ever goes onto the auxiliaryvlan.  Wireshark logs show the DHCP process goes properly as well, and the phone ACK's all of the DHCP parameters it accepts.  From that point forward, there is just no communication to the EIC server.  When the switch port doesn't have an auxiliaryvlan set (thus the phone is on the native vlan), the next thing I see after the DHCP Ack is TCP traffic to the HTTP boot server.

Unrelated, but just so information: The switch sees the device as "cisco+ieee".  The switch doesn't actually think it's a phone.  I know this because I tried using "set port qos 13/2 trust-device ciscoipphone" and the switch never enables QoS on the port for the phone so I use "set port qos 13/2 autoqos trust cos" instead

normally the switches see the cdp packet from the phone, before they allow traffic on the voice vlan.. cdp passes on voice vlan info with tagged frames to the switch port.. the switch can block traffic if cdpverify is disabled ... did you try enabling it now and see if it works ? can you also post other configs on the switch port related to cdp, portsecurity (if any) etc ?

with 3560, with voice vlan commands, you can detect cisco phones directly with commands, but not sure if you have equivalent commandsets in 8.4 for this.. the only way the switch recognises that it is a cisco phone is through CDP..

Raj