Yet, another VLAN thread

notgoing2failnotgoing2fail Member Posts: 1,138
Ok, sorry for all these VLAN threads, but I really need to understand the pruning part and how it affects broadcasts, multicasts and unicasts...

I thought that the side effects of VTP pruning was that broadcasts, multicasts and possibly unknown unicasts were not forwarded to the client switches. (switches in VTP client mode)

My lab doesn't seem to show that. Here's the setup.

server
transparent
client
(SwitchA)
(SwitchB)
(SwitchC)


I have one host on the switchA in server mode(with pruning) in VLAN 71.

I have one host on switchC in client mode in VLAN 71.

The transparent switchB is well, transparent....
SwitchB has VLAN 71 created, otherwise this entire lab would fail.



When I issue a broadcast ping on SwitchA from the host, the host on SwitchC responds!!

I also enabled RIP version 1 because it uses broadcasts (with debugging) and I can see the routers update each other....


To test out multicasts, I enabled version 2 for RIP and I was able to still see the updates coming in...



So could someone let me know what side effects VTP pruning can cause and what I need to do to simulate it?

Thanks!!

Comments

  • mikej412mikej412 Member Posts: 10,086 ■■■■■■■■■■
    The transparent switchB is well, transparent....
    SwitchB has VLAN 71 created, otherwise this entire lab would fail.
    What do you mean by fail? The host attached to Switch A in VLAN 71 wouldn't be able to ping the host attached to Switch C in VLAN 71?
    :mike: Cisco Certifications -- Collect the Entire Set!
  • peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    Since you have all three routers with VLAN71, there is no pruning (on VLAN71) taking place. Pruning is just preventing the switch from receiving VLAN packets for VLANs that do not belong to that switch.

    e.g. If your switch A&C are in server/client mode respectively, and you eliminated VLAN71 on switch B, the broadcast would only go to switch C via the trunk because switch B wouldn't have any hosts in VLAN71. I hope this helps.

    -Peanut
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • SelfmadeSelfmade Member Posts: 268
    It's not important to add reptutation points to others, but to be nice and spread good karma everywhere you go.
  • notgoing2failnotgoing2fail Member Posts: 1,138
    mikej412 wrote: »
    What do you mean by fail? The host attached to Switch A in VLAN 71 wouldn't be able to ping the host attached to Switch C in VLAN 71?


    Exactly. If the transparent switch doesn't also have VLAN 71, all the hosts on VLAN 71 on Switch C are isolated...

    If however I create VLAN 71 on SwitchB, then the traffic traverses through....
  • notgoing2failnotgoing2fail Member Posts: 1,138
    Selfmade wrote: »


    Yes I've read that as well as the flash video.

    My confusion is that a couple weeks ago, I got the impression that there was some side effect of pruning (or with no pruning, I'm not sure yet) of having transparent switches be in between the server and the client.

    Basically what I'm looking for is, what is that side effect....

    I've read that broadcasts, multicasts are not sent through, so I want to simulate that so I can see for myself....
  • notgoing2failnotgoing2fail Member Posts: 1,138
    Since you have all three routers with VLAN71, there is no pruning (on VLAN71) taking place. Pruning is just preventing the switch from receiving VLAN packets for VLANs that do not belong to that switch.

    e.g. If your switch A&C are in server/client mode respectively, and you eliminated VLAN71 on switch B, the broadcast would only go to switch C via the trunk because switch B wouldn't have any hosts in VLAN71. I hope this helps.

    -Peanut


    I don't believe that is the case though. If VLAN 71 doesn't exist on Switch B (the transparent switch), I cannot get ANY communications whatsoever between Switch A and Switch C.

    If I hook up Switch C to Switch A and bypass the transparent switch, then obviously everything works.

    If I change the transparent switch to client mode, then everything works.

    Basically when the transparent switch does not have VLAN 71, then all hosts in Switch C are dead in the water.

    Is that how it's suppose to work?
  • peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    I don't believe that is the case though. If VLAN 71 doesn't exist on Switch B (the transparent switch), I cannot get ANY communications whatsoever between Switch A and Switch C.

    As long as you have trunk links, then you'll still have communications. VTP transparent mode just means that your switch will not advertise its vlan database and it will also ignore updates sent to him. If I'm not mistaking, the a transparent switch will still forward the vtp advertisements and a trunk should not be affected. Since the trunk is not affected, switch B shouldn't stop forwarding packets because its in transparent mode.

    Basically when the transparent switch does not have VLAN 71, then all hosts in Switch C are dead in the water.

    Is that how it's suppose to work?

    I don't think that's true... your trunk is what carries the VLAN data. This is not going to be affected by a transparent switch. HTH.

    -Peanut
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    As long as you have trunk links, then you'll still have communications. VTP transparent mode just means that your switch will not advertise its vlan database and it will also ignore updates sent to him. If I'm not mistaking, the a transparent switch will still forward the vtp advertisements and a trunk should not be affected. Since the trunk is not affected, switch B shouldn't stop forwarding packets because its in transparent mode.

    Not when pruning is involved.

    Cisco specifically says the following of VTP transparent and pruning:

    VTP pruning is not designed to function in VTP transparent mode. If one or more switches in the network are in VTP transparent mode, you should do one of these:

    •Turn off VTP pruning in the entire network.

    •Turn off VTP pruning by making all VLANs on the trunk of the switch upstream to the VTP transparent switch pruning ineligible.


    And even when you take VTP out of the picture entirely, just having a trunk link doesn't mean the switch is going to pass along info for frames tagged for vlans it doesn't know about.

    Let me give you an example -

    Here's the progression of connections:

    [Distribution Switch] -> [Access Layer Switch] -> [Another Access Layer Switch]

    Ok, so you've got them daisy chained. There's a trunk between the Distribution switch and the Access Layer Switch, and there's another trunk between the Access Layer Switch and Another Access Layer Switch.

    Distribution switch has vlan's 5 through 20 on it. The Access Layer Switch has vlans 10 through 20 on it. The Another Access Layer Switch has hosts in Vlans 5 and 20.

    I manually define which vlans are allowed on trunks. Now, I define Vlans 5 and 20 as allowed on the trunk betwen ALS and AALS, and I add vlan 5 to the vlans allowed on the Distribution to ALS trunk.

    AALS will only receive frames in vlan 20. Why? because vlan 5 doesn't exist on ALS. The second I issue the command vlan 5 on ALS, AALS starts populating it's cam with MAC's from vlan 5.

    In order to pass the vlan on the trunk, the switch has to have that vlan configured, even if it doesn't have any ports in it
  • peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    Not when pruning is involved.

    Cisco specifically says the following of VTP transparent and pruning:

    VTP pruning is not designed to function in VTP transparent mode. If one or more switches in the network are in VTP transparent mode, you should do one of these:

    •Turn off VTP pruning in the entire network.

    •Turn off VTP pruning by making all VLANs on the trunk of the switch upstream to the VTP transparent switch pruning ineligible.

    I wasn't aware of that... thanks!
    And even when you take VTP out of the picture entirely, just having a trunk link doesn't mean the switch is going to pass along info for frames tagged for vlans it doesn't know about.

    Let me give you an example -

    Here's the progression of connections:

    [Distribution Switch] -> [Access Layer Switch] -> [Another Access Layer Switch]

    Ok, so you've got them daisy chained. There's a trunk between the Distribution switch and the Access Layer Switch, and there's another trunk between the Access Layer Switch and Another Access Layer Switch.

    Distribution switch has vlan's 5 through 20 on it. The Access Layer Switch has vlans 10 through 20 on it. The Another Access Layer Switch has hosts in Vlans 5 and 20.

    I manually define which vlans are allowed on trunks. Now, I define Vlans 5 and 20 as allowed on the trunk betwen ALS and AALS, and I add vlan 5 to the vlans allowed on the Distribution to ALS trunk.

    AALS will only receive frames in vlan 20. Why? because vlan 5 doesn't exist on ALS. The second I issue the command vlan 5 on ALS, AALS starts populating it's cam with MAC's from vlan 5.

    In order to pass the vlan on the trunk, the switch has to have that vlan configured, even if it doesn't have any ports in it

    I understand that portion... I was thinking along the lines of having VTP running (no pruning) and no transparent switch. Then both routers would have the same VLAN database as long as VTP is properly configured. Sorry if I didn't convey that in my response. Thanks for the write up! That's why I love this forum... constantly learning something! icon_cheers.gif

    -Peanut
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • mikej412mikej412 Member Posts: 10,086 ■■■■■■■■■■
    I got the impression that there was some side effect of pruning
    Exactly. If the transparent switch doesn't also have VLAN 71, all the hosts on VLAN 71 on Switch C are isolated...

    Wouldn't you consider that a pretty drastic side effect of enabling pruning when you've got a transparent switch stuck in you hierarchical switch structure and it drops traffic that downstream switches would like to receive?
    :mike: Cisco Certifications -- Collect the Entire Set!
  • notgoing2failnotgoing2fail Member Posts: 1,138
    mikej412 wrote: »
    Wouldn't you consider that a pretty drastic side effect of enabling pruning when you've got a transparent switch stuck in you hierarchical switch structure and it drops traffic that downstream switches would like to receive?


    This side effect occurs when pruning is disabled as well...

    Basically, I cannot tell the difference when pruning is enabled or disabled.


    If pruning is disabled, I still cannot have hosts on Switch C access hosts on Switch A through Switch B....


    But based on what Forsaken_GA said, this looks like the correct behavior...


    At the end of the day, I'm just not going to ever mix transparent switches in a production environment...that I know....I suppose in a lab environment, I just want to play with the "ill" effects.

    I haven't really seen anything wrong with VTP pruning enabled that VTP pruning disabled doesn't do.....
  • notgoing2failnotgoing2fail Member Posts: 1,138
    Not when pruning is involved.

    Cisco specifically says the following of VTP transparent and pruning:

    VTP pruning is not designed to function in VTP transparent mode. If one or more switches in the network are in VTP transparent mode, you should do one of these:

    •Turn off VTP pruning in the entire network.

    •Turn off VTP pruning by making all VLANs on the trunk of the switch upstream to the VTP transparent switch pruning ineligible.


    And even when you take VTP out of the picture entirely, just having a trunk link doesn't mean the switch is going to pass along info for frames tagged for vlans it doesn't know about.

    Let me give you an example -

    Here's the progression of connections:

    [Distribution Switch] -> [Access Layer Switch] -> [Another Access Layer Switch]

    Ok, so you've got them daisy chained. There's a trunk between the Distribution switch and the Access Layer Switch, and there's another trunk between the Access Layer Switch and Another Access Layer Switch.

    Distribution switch has vlan's 5 through 20 on it. The Access Layer Switch has vlans 10 through 20 on it. The Another Access Layer Switch has hosts in Vlans 5 and 20.

    I manually define which vlans are allowed on trunks. Now, I define Vlans 5 and 20 as allowed on the trunk betwen ALS and AALS, and I add vlan 5 to the vlans allowed on the Distribution to ALS trunk.

    AALS will only receive frames in vlan 20. Why? because vlan 5 doesn't exist on ALS. The second I issue the command vlan 5 on ALS, AALS starts populating it's cam with MAC's from vlan 5.

    In order to pass the vlan on the trunk, the switch has to have that vlan configured, even if it doesn't have any ports in it


    Yes this is exactly the scenario that I am experiencing!!!

    So it looks like I am labbing it correctly after all....


    I can tell you this, and perhaps I'm not a good reader, but from my CCNA studies, I walked away getting the impression that hosts on Switch C will still be able to communicate with Switch A through ANY transparent switch. This obviously is not the case.
    I'm so glad that I labbed this up and did not take for granted what I thought I was reading in the CCNA book...

    I have yet to simulate the ill effects of pruning but I guess I'll just have to save that for another day....
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    Yes this is exactly the scenario that I am experiencing!!!

    I have yet to simulate the ill effects of pruning but I guess I'll just have to save that for another day....

    Erm, yes you have :) Having your vlans partitioned because of VTP pruning is something widely considered an 'ill effect'
  • notgoing2failnotgoing2fail Member Posts: 1,138
    Erm, yes you have :) Having your vlans partitioned because of VTP pruning is something widely considered an 'ill effect'


    I don't understand that comment? icon_redface.gif

    What do you mean by having the vlans partitioned?
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    I don't understand that comment? icon_redface.gif

    What do you mean by having the vlans partitioned?

    Well the idea is for switch a to be able to communicate with switch c within the same vlan right? To appear logically as one whole

    Instead, you have two halves, ie, your vlan is partitioned. This is not something that would generally be considered a good thing. Unless the hosts on switch A think the hosts on switch C are a bunch of bungholes and don't want to talk to them anyway.
  • notgoing2failnotgoing2fail Member Posts: 1,138
    Well the idea is for switch a to be able to communicate with switch c within the same vlan right? To appear logically as one whole

    Instead, you have two halves, ie, your vlan is partitioned. This is not something that would generally be considered a good thing. Unless the hosts on switch A think the hosts on switch C are a bunch of bungholes and don't want to talk to them anyway.


    Right ok...now I understand.

    But I have this issue regardless of VTP pruning. I think that's where the confusion is coming in.

    VTP pruning seems to be blamed for ill effects, but if I disable it, I don't see any difference, I still cannot access hosts on Switch C UNLESS Switch B (transparent switch) includes the "VLAN 71" in its own VLAN database..

    I guess what's frustrating me is that I'd like to simulate issues pertaining to VTP pruning, but I don't know how or what the side effects of VTP pruning are...
Sign In or Register to comment.