Task 1.1 Pruning

Why sw1 fa0/19 and sw4 fa0/13 need switport trunk allowed vlan 3003? should be sw tr all vl none on these two links?

 

Vlan 3003 is only present on sw3 fa0/3 to R3.

Comments

  • That´s right. It seems they were working another topology. If you copy the SG into the lab it doesn´t work.

    This is the config I did and everything seems fine:

    SW1

    interface FastEthernet0/14
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 16,45,47,100,200

    interface FastEthernet0/19
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 45

     

    SW2

    interface FastEthernet0/6
     switchport trunk encapsulation dot1q
     switchport trunk allowed vlan 16,63

    interface FastEthernet0/14
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 16,45,47,100,200

    interface FastEthernet0/16
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 45,63

    SW3

    interface FastEthernet0/16
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 45,63

    SW4

    interface FastEthernet0/13
     switchport trunk encapsulation isl
     switchport trunk allowed vlan 45

  • Sorry, didn´t quite get next task 1.2. So you can take out vlan 45 from the advertisements. In the interfaces where vlan 45 is the only one in the command, I used vlan 1.

  • Hi thanks for the post you actually forget to include vlan 38 on the trunk link between SW1 and SW2 :)

  • ooops don`t need to incldue the vlan 38 :)...don`t pay attention :)

     

    Thanks

  • I came up with the same config.

    This is one for the TechEdit team :)

    Eric

  • One thing we have to keep in mind is it depends also on who the root bridge is. If you copy the SG into your rack, it might not work because your using different switches with different MAC address hence different root bridges. All traffic has to flow to the root bridge, so the traffic flow would be different depending on who is the root. 

    This problem would not arise if all switches had trunks to each other, but that's not the case here. 


    HTH

  • Hi all,

      May updates contain this fix as well. Thank you for your patience.

    Regards,

  • SG is not updated yet, I am using ver v5.10.0.18 version.

  • I got the same solution as you except for VLAN45. You don't need to allow VLAN45 on any trunk interface because VLAN45 doesn't exist on either SW1 or SW2. VLAN45 only exists on SW3 and SW4 and that VLAN is linked together on task 1.2 via metro tags 100 and 200 on SW1 and SW2.

  • Another concern;

    Look at the example:

    In Task 1,2 we are NOT ADDING vlans 100,200 to trunk between SW1 and SW2. Why? These vlans are needed here, if vtp pruning were enabled, it wouldn't prune those vlans from trunks, because they are configured on tunnel ports.

    The reasons why SG says that we should allow them in task 1.2 not 1.1 are unknown to me.

    If we follow the same strategy, we should not prune vlan45 between SW1 and SW4 in task 1.1 (still needed here), and *eventually* do it only after doing task 1.2.

    SG seems to mix up solutions for those two tasks together.

    I wrote "eventually" because no statement in Task 1.2 says, that vlan45 cannot be forwarded on trunk between SW1 and SW3.

     

  • This Task is quite confusing :(, Prunning mean, The switches must prunned the "not intended"
    vlan out of its interface. My solution was configured all the switches to become
    vtp mode server, after that enable prunning, then see manually which vlans
    were allowed, then changed back all the switches into the transparent mode
    then do the same config as if the prunning mode on

     

    is my solution considered correct?

    since I did look the prunning work on the switches before I configured

  • I didn't think it was possible to spend the best part of a day on one task, but apparently it is! Heaven help me in the exam.

    OK, so I thought I'd give hamsterviel's method a try & see exactly how VTP pruning works left to its own devices. The pruning as seen from one end of a trunk will not be the same as the other end. Therefore, this creates confusion knowing what to disallow on the trunk exactly.

    Now, the bit that's really confusing me is with VLAN5. This is local to the segment between SW1 and R5, yet appears not to get pruned on all the trunks. Why?!

    I've attached the key parts of the topology & relevant 'show' outputs. I came to the conclusion that this sort of questoin is best answered by way of inspection. ie Pore over the topology & just study carefully where exactly the VLANs reside & which trunks need to be traversed in order to link them up. Fine if there's no pressure on time, but  in an exam?! What a nightmare.

     

    Not sure what happened there. Here's the image in its entirety anyway ..
    http://tinypic.com/view.php?pic=2v3ooaw&s=7

     

    Pruneimage

  • Tha answer lies in the definition of pruning mechanism itself. If for example pruning is enabled and i as a switch have access ports in up state for vlans 3,4,5 and have been requested by a neighbor switch of mine for vlans 7,8,9, on all the other trunks i will request to receive traffic for vlans 3,4,5,7,8,9. Think that SW1 has no idea that VLAN5 is only locally attached and is normal to ask for traffic of that vlan out on all its trunk ports. This is why SW4 shows it's forwarding traffic for VLAN5 towards SW1. Nowadays, because of strange behaviors pruning might lead to, and because its incompcatibility with VTP transparent, most designs use manual VLAN prunning by command "switchport trunka llowed vlan".

    Hope it helps, otherwise let me know.

    All the best!

  • I actually put all switches in client/server vtp mode, then enabled pruning and it gave me interesting results. Some trunks were pruned on one end of the link, but not the other. I guess it would still stop broadcasts from propagating. Lesson learned - just get L2 stuff working, forget about the points.

  • his Task is quite confusing :(, Prunning mean, The switches must prunned the "not intended"
    vlan out of its interface. My solution was configured all the switches to become
    vtp mode server, after that enable prunning, then see manually which vlans
    were allowed, then changed back all the switches into the transparent mode
    then do the same config as if the prunning mode on

    Thats an interesting way of solving a problem but it does not work if we hav vlans in extended range else in that case we have to make couple of additional changes like removing and again adding those extended vlan and also need to manually allowed vlan for extentended vlan range.

  • I came up with a solution that worked and then changed it to meet the SG which broke connectivity.  Thanks for all of the suggestions that were provided here.

  • This task is quite confusing...and from my point of view I think the SG doesn't mimic VTP completely, the following points


    • in my LAB  have SW3 as the RootBridge
    • Just to compare with my config, I also activated VTP server (removed vlan 3003)
    • Take the example of Vlan 45, Since R5 F0/1 is in SW3....SW4 will get a request to forward this vlan....the SG is not allowing any VLAN on SW4 F0/13......What am I missing here ?


    Rack17SW4#sh int trunk                         


    Port        Mode             Encapsulation  Status        Native vlan

    Fa0/13      on               isl            trunking      1


    Port        Vlans allowed on trunk

    Fa0/13      1-4094


    Port        Vlans allowed and active in management domain

    Fa0/13      1,5,16,22,38,45,47,63,100,200,999


    Port        Vlans in spanning tree forwarding state and not pruned

    Fa0/13      1,5,16,22,38,45,47,63


Sign In or Register to comment.