Switch Questions

1. If all the ports on the unmanaged switch will be in the same VLAN then you can just hook it up to an access port. If you hook it up to a trunk then the native VLAN on that trunk will have to match the single VLAN all devices are in. That kind of defeats the whole purpose of a trunk.

2. When you do a switchport with a data VLAN and a voice VLAN you are just making it a trunk anyway. It just relies on CDP to form that trunk with the phone. If they are non Cisco phone you made need to hard code a trunk for it to work properly.

3. You technically shouldn't see the non broadcast traffic no matter what your native is. Best practices are to set the native to a non used VLAN, but the vast majority of networks I have seen leave the default native and just do not use VLAN 1 for user or management data.

Damn dude! Guess that's the difference between a noob and a experience pro lol.

networker050184 wrote: »

1. If all the ports on the unmanaged switch will be in the same VLAN then you can just hook it up to an access port. If you hook it up to a trunk then the native VLAN on that trunk will have to match the single VLAN all devices are in. That kind of defeats the whole purpose of a trunk.

Ok so if I do switchport mode access and specify my user Vlan on the 3560 then on all of the devices of unmanaged switch will be able to interact with devices on other switches in the same vlan (on managed switches or unmanaged switches) correctly?

networker050184 wrote: »

2. When you do a switchport with a data VLAN and a voice VLAN you are just making it a trunk anyway. It just relies on CDP to form that trunk with the phone. If they are non Cisco phone you made need to hard code a trunk for it to work properly.

These are non cisco phones (which is part of the problem with our QoS). We want to get the voice stuff on the POE switches and the desktops on another switch so at some point I can just make the ports to the phones access ports with the voice vlan specified.

networker050184 wrote: »

3. You technically shouldn't see the non broadcast traffic no matter what your native is. Best practices are to set the native to a non used VLAN, but the vast majority of networks I have seen leave the default native and just do not use VLAN 1 for user or management data.

Then what's the point of changing the naive Vlan? My understanding is the native vlan is a catch all for all non tagged traffic and such. Lets say I have some traffic that isn't tagged and the native vlan between two ports is like 2 or 15 or whatever. Is that just locally significant? What I mean is, wouldn't it just send that traffic to Vlan 2 or 15 AND all ports belonging to 2 or 15 since it is set to an actively used Vlan? Isn't that the whole point of changing it to an unused vlan?

Maybe I'm "corn-fused" but that is my understanding.

knwminus wrote: »

Ok so if I do switchport mode access and specify my user Vlan on the 3560 then on all of the devices of unmanaged switch will be able to interact with devices on other switches in the same vlan (on managed switches or unmanaged switches) correctly?

Yep.

knwminus wrote: »

Then what's the point of changing the naive Vlan? My understanding is the native vlan is a catch all for all non tagged traffic and such. Lets say I have some traffic that isn't tagged and the native vlan between two ports is like 2 or 15 or whatever. Is that just locally significant? What I mean is, wouldn't it just send that traffic to Vlan 2 or 15 AND all ports belonging to 2 or 15 since it is set to an actively used Vlan? Isn't that the whole point of changing it to an unused vlan?

Maybe I'm "corn-fused" but that is my understanding.

The point of changing the native VLAN to an unused VLAN is to stop VLAN hopping and to prevent user traffic from interfering with management protocols that use VLAN 1. The native VLAN is only significant on that single trunk you assign it on. Traffic that arrives on the trunk untagged will be assumed to be a part of the native VLAN. It won't allow traffic to bleed over or be a part of two VLANs as you suggested. Something to keep in mind is that tags ONLY exist on trunk ports. The point of the tags are to separate the traffic as it traverses the trunk. The CoS bits are only carried in the tag. This is something that confuses people a lot when they try to implement layer 2 QoS schemes.

networker050184 wrote: »

Yep.

The point of changing the native VLAN to an unused VLAN is to stop VLAN hopping and to prevent user traffic from interfering with management protocols that use VLAN 1. The native VLAN is only significant on that single trunk you assign it on. Traffic that arrives on the trunk untagged will be assumed to be a part of the native VLAN. It won't allow traffic to bleed over or be a part of two VLANs as you suggested. Something to keep in mind is that tags ONLY exist on trunk ports. The point of the tags are to separate the traffic as it traverses the trunk. The CoS bits are only carried in the tag. This is something that confuses people a lot when they try to implement layer 2 QoS schemes.

Ok. Thanks for the clarification. I guess I am going to have to do more investigation to find out what's up with all that traffic then.

networker050184 wrote: »

2. When you do a switchport with a data VLAN and a voice VLAN you are just making it a trunk anyway. It just relies on CDP to form that trunk with the phone. If they are non Cisco phone you made need to hard code a trunk for it to work properly.

A lot of the VoIP phone vendors support CDP now. Polycom is one example, we use them instead of Cisco since we're an I3 shop. They work great with the voice vlan command.

burbankmarc

Nuul wrote: »

A lot of the VoIP phone vendors support CDP now. Polycom is one example, we use them instead of Cisco since we're an I3 shop. They work great with the voice vlan command.

Same with Nortel phones.

Nuul wrote: »

A lot of the VoIP phone vendors support CDP now. Polycom is one example, we use them instead of Cisco since we're an I3 shop. They work great with the voice vlan command.

I3 as in Interactions gateway?

We are using polycom phones as well and I was just able to do a proof of concept on my phone. We don't want users using the switching feature on the phone. We want them using the data jacks which actually terminate into a different set of switches in our Server Room. The previous admin had basically every port as a trunk port but I just made the phone ports access ports for only the voice vlan with sticky macs and a violation shutdown. It is working just fine like I thought it would. Even works with the phone software like a champ. The company that came in said that the native vlan had to be the data vlan and I still cannot figure out why. But regardless of that I have it working on access ports. Small victory!

knwminus wrote: »

I3 as in Interactions gateway?

No, we don't use their gateways. We use CIC 3.0 from them though.

knwminus wrote: »

We don't want users using the switching feature on the phone. We want them using the data jacks which actually terminate into a different set of switches in our Server Room.

...why? You now have to have double the switch ports for no reason.

knwminus wrote: »

The previous admin had basically every port as a trunk port but I just made the phone ports access ports for only the voice vlan

I think I know what you're saying. Something like this?

 switchport access vlan [voicevlan]
 switchport trunk encapsulation dot1q
 switchport trunk native vlan [datavlan]
 switchport trunk allowed vlan 1,[datavlan],[voicevlan]
 switchport mode trunk
 speed 100
 duplex full
 priority-queue out
 mls qos trust cos

It's essentially the same thing as this but this is cleaner.

 switchport access vlan [datavlan]
 switchport voice vlan [voicevlan]
 speed 100
 duplex full
 priority-queue out
 mls qos trust cos
 spanning-tree portfast

Nuul wrote: »

...why? You now have to have double the switch ports for no reason.

Because the company who set up our phone system (before my time) said it is in our best interest to physically seperate the voice and data traffic. We don't have any more spare 3560s but we have tons of unmanaged switches with gig ports. We are going to move all of the desktops to the unmanaged stuff and keep all of the voice stuff on the 3560s effectively
freeing up 2 of our 3560 switches.

We are having some QoS problems and they said that this will help them help us.

Nuul wrote: »

I think I know what you're saying. Something like this?

 switchport access vlan [voicevlan]
 switchport trunk encapsulation dot1q
 switchport trunk native vlan [datavlan]
 switchport trunk allowed vlan 1,[datavlan],[voicevlan]
 switchport mode trunk
 speed 100
 duplex full
 priority-queue out
 mls qos trust cos

It's essentially the same thing as this but this is cleaner.

 switchport access vlan [datavlan]
 switchport voice vlan [voicevlan]
 speed 100
 duplex full
 priority-queue out
 mls qos trust cos
 spanning-tree portfast

Exactly. The only command I don't get is the mls qos trust cos. When I disabled CDP on my port (for testing) I noticed that I got a message saying that the port was untrusted. However my phone still worked and everything was fine. I did reenable that command and I am about to do some research on why it is there.

Just so you know, someone ran auto qos on our switches and apparently we needed to go in and fine tune the qos settings (again before my time) but that didn't happen. I would like to figure it out myself and fix it and save us some money but I don't understand QoS (yet).

Ah, OK. I saw the unmanged switch comment of yours earlier but it didn't click for some reason. Not having enough managed switches to go around makes a big difference.

The reason for the mls qos trust cos command is to tell the switch that you trust the qos markings it sees on that port (basically from the phone). I set that on my port channels going back to the core too.

Nuul wrote: »

Ah, OK. I saw the unmanged switch comment of yours earlier but it didn't click for some reason. Not having enough managed switches to go around makes a big difference.

The reason for the mls qos trust cos command is to tell the switch that you trust the qos markings it sees on that port (basically from the phone). I set that on my port channels going back to the core too.

... and the COS would be communicated from the phone via CDP right? That makes sense because the port said untrusted so I guess it just used defaults or something (since it still worked and all)?

I really need to get into my network warrior book or the wendell book and read about QoS so I can save us about 1500 dollars on outside support.

burbankmarc

COS is the frame marking for the priority of the traffic. There are 8 values 0-7. Most people match EF with CoS 5.

I prefer matching DSCP since I can split my traffic up a lot more. I'm currently doing that for all my Nortel media gateway cards.

You'll also want to start looking into queueing, and you have 3560's so check out SRR.

*EDIT*

http://en.wikipedia.org/wiki/Class_of_service

http://cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_37_se/configuration/guide/swvoip.html

The CoS is communicated in the 802.1q header. It has nothing to do with CDP. CDP is only there to recognize the device as a phone. I'm not sure why removing CDP affected that command though. I believe CDP is only used for the trust when you have the mls qos trust device cisco-phone. I could be mistaken though.

networker050184 wrote: »

The CoS is communicated in the 802.1q header. It has nothing to do with CDP. CDP is only there to recognize the device as a phone. I'm not sure why removing CDP affected that command though. I believe CDP is only used for the trust when you have the mls qos trust device cisco-phone. I could be mistaken though.

I think you are correct because that line of text is in the config

interface FastEthernet0/9
switchport access vlan XX
switchport trunk encapsulation dot1q
switchport trunk native vlan XX
switchport mode trunk
switchport voice vlan XX
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone

networker050184 wrote: »

I'm not sure why removing CDP affected that command though.

I think the reason it didn't work was because CDP is used in conjunction with the voice vlan command to make a 2 vlan trunk on that port. No CDP, no trunk. I found this out the hard way when I was going through all our switches and converting the configs from trunks (first example I showed in my post above) to using the voice vlan command.

Nuul wrote: »

I think the reason it didn't work was because CDP is used in conjunction with the voice vlan command to make a 2 vlan trunk on that port. No CDP, no trunk. I found this out the hard way when I was going through all our switches and converting the configs from trunks (first example I showed in my post above) to using the voice vlan command.

I'm pretty sure its the "mls qos trust device cisco-phone" command that caused it.