Pinging across Intevlan/Subinterfaces

[eriktatsapaugh]

I'm looking for help with a problem that is driving me crazy, because I know that it must be something simple that I've missed.

I've attached the switch (3550) and router (2811) configs. Nut shell: I am unable to ping from router to switch, or switch to router. I'm trying to get two 7060s to function via CME (on same switch) using the router-on-a-stick setup. The phones were working at one point, I discovered that I could not PING, tried to fix it, and phones stopped working. Tried to fix by going back to a previous config set, but no luck. Since then I've deleted all configs and vlan.dat and started from scratch.

A computer attached to 0/23 did receive a correct IP address via DHCP, if the port is set as a vlan 100 access port, but not when configured as a dot1q trunk. In configs, RLR is the router, RLS is the switch.

Secondary, if anyone can spot any addressing mistakes with the IP telephony section, I would be most appreciative of suggested corrections.

Thank you,

Erik

[Richard Burts]

Erik

I have looked at the configs that you posted and I believe that I see several issues. First and most important, you can not ping the switch because there is no management interface with an IP address. You define 2 VLAN interfaces but neither has an IP address. Assuming that this is a layer 2 switch it would use a single VLAN interface as its management interface. (If you try to configure 2 VLAN interfaces with IP addresses one of the interfaces would go to shutdown state). And the management interface needs an IP address.

I am also surprised that all the switch interfaces are configured as trunks. Configuring switch ports as trunks makes sense if it is to connect to another switch or router doing trunking, or perhaps connecting to some server whose NIC is smart enough to do trunking. But for most end stations the switch interface should be configured as an access port. This explains why the computer on 0/23 did get a DHCP address when configured as an access port but not when configured as a trunk - I doubt that the computer was processing fot1Q trunking. An untagged frame from the computer would be treated as part of the native VLAN and since you do not configure a native VLAN (or configure VLAN 1 which is the default native VLAN) its frame is not processed.

HTH

Rick

[eriktatsapaugh]

Thank you. The ping problem went away with the inclusion of a native vlan w/ ip address on the switch. As for the phones, they still do not receive an IP address from DHCP. I have the switchports in trunk mode for three reasons (which doesn't mean they are GOOD reasons) 1) I am copying a config from a successfully running, in-use VoIP switch, 2)this is the way I remember being taught to do it if there are going to be computers connecting to the switch through the IP phone's built in switchports. 3) Trunks are whats shown in the Cisco doc for the 3550 switch when doing VoIP. This setup allows for a data vlan as well as a phone vlan, as I undestand it. However, I am certainly open to finding a better way, as this isn't currently working.

I've attached configs UPDATED from previous post. Changed vlan info to match on switch and router. (oops) Still no luck

RLS: Switch

RLR: Router

[Richard Burts]

Erik

I am glad that my suggestion helped you solve the problem of pinging the switch. I wonder if the remaining problem is related to trunking and the native VLAN. When a device boots up and sends an untagged frame it will be treated as being in the native VLAN which is VLAN 1 by default. I do not see anything that tells the device that data should be in VLAN 100 and suspect that a major part of the problem is that the DHCP requests (at least for data) are generated in VLAN 1.

If you are following a working example then we should expect it to work. As to whether it constitutes a good example, I will note that I found this paragraph (or one very similar) in several of the discussions of configuring IP phones that I checked:

When you connect an IP phone to a switch using a trunk link, it can cause high CPU utilization in the switches. As all the VLANs for a particular interface are trunked to the phone, it increases the number of STP instances the switch has to manage. This increases the CPU utilization. Trunking also causes unnecessary broadcast / multicast / unknown unicast traffic to hit the phone link.

So my initial suggestion would be to make the switch ports to which phones will connect to be access ports in VLAN 100. Or if you prefer to continue with your example (and I can understand that you might prefer this) then I would suggest that you move the data VLAN to VLAN 1 or else identify VLAN 100 as the native VLAN.

HTH

Rick