Just a quick quesiton; is the "span bpdufil enable" command just a best practice in the solution ? (or perhaps there is a very reason for that!)...
I have the same question.
this is a bit late as you both are way ahead of me and i'm just doing this lab, but the doc cd definitely includes adding the "spanning-tree bpdufilter enable" in step 8 of one of Cisco's examples. my guess is for protection from the service provider's side of things.
my question to you both is that i only used one metro vlan 100 and applied that to all four ports and it seems to be working here. in the SG, for some reason they use two (unless of course it is just another typo) and they apply it two different sets of ports. pretty bizzare!
You can also use the spanning-tree bpdufilter enableinterface configuration command to enable BPDU filtering on any portwithout also enabling the Port Fast feature. This command prevents theport from sending or receiving BPDUs.
a little update:
although, the task only allows you to create one additional VLAN, one for the METRO VLAN (outer VLAN) that will essentially be carrying the customer's inner VLAN, i'm wondering why the SG used two separate VLANs, 100 and 101. is this just another infamous typos?
the reason i bring this up is that while finishing up some other tasks within this lab, i noticed this unusual error message on SW1, the one doing the dot1q tunneling:
from what I gathered online apparently it is a common behavior. see below. in the interim, i will leave it alone. i might try adding that other VLAN 101, but it seems to sure violate the task giving us only VLAN 100 to add for this solution.
Re: %SW_MATM-4-MACFLAP_NOTIF and q-in-q tunnels... Remove Highlighting [In reply to]I had the same problem, but it was normal.Although the mac address is the same, the inner (customer) vlan is different, so from customer sideeverything is fine.From provider side, since you're using a common outer vlan, you'll have the same mac address from 2different ports, but on the same (outer) vlan...which is a no-no.The only solution i found (since my topology was p2p for this vlan), was to disable mac learning forthis outer vlan.I guess MAC-in-MAC (802.1ah) would solve such a problem (there are some pdfs referencing 6500 and802.1ah, but i haven't seen this feature appearing in any ios release).
i've noticed that ur post dates back while now. but in case u ever got an answer for ur question regarding vlan 100 and vlan 101 please share it
for i have the same issue
ive created on vlan 100 and it seems to be working just fine
i remember this lab really well and while the task only allows one vlan to be added, yet the sg uses two, the correct answer is you will in fact need two vlans. in addition, let's say if sw3 trunked over three ports instead of two, to sw4, then on sw1 (the ISP switch) you would then need 3 metro vlans, one for each port. this is by design. otherwise, mac flaps will occur.
hope this helps.
thx for your reply
i did configure only 1 vlan and it worked just fine and i was able to run my routing protocols over it normally.
and i didnt get any mac flaps. could you please elbaorate on the mac flap issue.
Is this type of practice ( i.e configuring 2 Vlans ) documented somewhere
following this link http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_46_se/configuration/guide/swtunnel.html#wp1027765 and go to the figure titled "Figure 16-6 Layer 2 Protocol Tunneling for EtherChannels". i believe the Cisco diagram depicting the configuration we are simulating in IE labs pretty much spells it out that you need more than one Vlan. If I find anything else on the mac flapping I will let you know. Interesting you didn't see the errors. Could it be that one of your ports was disabled or shutdown?
thx for the link. i went through it carefully.
1- it's true that it shows that they are using multiple vlans but they are not saying WHY
in addition to that their scenario is for etherchannel negotiation with the command
l2protocol-tunnel point-to-point not sure how much it is relevant but it could be as for the errors of mac flapping i didn't get any and both of my ports are functional. but the funny part is that i have l2pt for cdpand when i do show cdp neigh fast0/14 on sw3 i get the following ports:fast0/15 of sw3fast0/14 of sw4fast0/15 of sw4when i do show cdp neigh fast0/15 on sw3 i get the following ports:fast0/14 of sw3fast0/14 of sw4fast0/15 of sw4same results for switch 4thx a lot,hadi
looks to me like you do have a loop going on there, even though you are not getting the mac address flap issue.
as for the the need for "l2-protocol-tunnel point-to-point", the reason it is used in this Cisco doc and configuratioin example is because on the customer switches the channel-group mode that was used for the etherchannel config was "desirable" which sends PAgP (desirable or auto). in this task, there was no mentioned of a specific link aggregation, hence, "channel-group mode on" was sufficient along with no need for "l2-protocol-tunnel point-to-point". the reason you will use and configure "l2-protocol-tunnel point-to-point" on the switch providing the L2 tunnel (a.k.a. SW1 Service Provider Switch) is to enable PAgP, LACP, or UDLD, etc in order to pass that specific link aggregation negotiation protocol from the customer switches (i.e. SW3 and SW4) when they are specifically configured either with "channel-group mode [auto|desirable] for PAgP or "channel-group mode [active|passive] for LACP.
does that make sense?
yes it does
but i'm still stuck with the same question why do i need more than a single vlan. it doesnt make sense to me at all. i mean a single vlan is working just fine
although they are using multiple vlans on the cisco website. they just don't mention WHY
I mean my configuration has a single vlan and it's working just fine.
Let me reprhase my question. when do i need a single VLAN and when do i need Multiple VLANS and why ?
i will post that question on the globa forum as well to see what i get
You need two vlans, One for the Metro vlan(Service provider vlan 100) and other one for carrying customer vlan (101) inside the metro vlan. So you need to increase your mtu size which may cause problem for OSPF where you have to give a command in ospf to ignore the MTU size.
the customer traffic is untagged since the service provider is connected to a layer 3 port
the question was why do we need on the service provider end to assign two seperate vlans one on each port
actually, this is incorrect. be careful with this configuration. the outer vlan (a.k.a. metro vlan) configured on sw1 (a.k.a. SP edge switch) in this task can carry multiple, in fact all of the vlans (a.k.a. inner vlan) within the trunk coming from the customer. hence the switchport mode access vlan command configured on the SP switch is not supposed to match the vlans the customer has. this is simply the metro vlan configuration.
does this make sense?
after a long look into "why" there is a need to have separate vlans for each port, when there is more than one port coming from the customer switch as is the case here and due to etherchannel, i have come up empty. my only guess is that we reach out to IE experts for some clarification. i will send an email to one of them.
since your test proved you needed need it and did not run into mac addresses flappping, i will redo a lab of mine and will use 4 or even 8 ports within one etherchannel and see if i run into any issues.
more to follow here.
Thx a lot for your continous support. If u can get an input from one of the experts on why we need more than a single vlan that would be great.
thx a lot
okay, i did some extensive testing just an hour ago and here is what i have. first off, before anything, i still have no reason why you need multiple METRO vlans, and i can be completely wrong, and the Cisco article could be a misinterpretation of mine, but in my testing, things little a bit more stable and normal with multiple vlans for each Layer 2 path. i have all my testing in a notepad and if you want to see it all, email me at [email protected], but for now, here are the findings.
with one METRO vlan 100 on all ports f0/13-18 on configured on sw1 using the lab diag below:
the following results were found:
sw2(config-if-range)#do sh cdp neigh | i sw3sw3 Fas 0/15 167 S I WS-C3560- Fas 0/15sw3 Fas 0/14 167 S I WS-C3560- Fas 0/15sw3 Fas 0/13 167 S I WS-C3560- Fas 0/15sw3 Fas 0/15 167 S I WS-C3560- Fas 0/14sw3 Fas 0/14 167 S I WS-C3560- Fas 0/14sw3 Fas 0/13 167 S I WS-C3560- Fas 0/14sw3 Fas 0/15 167 S I WS-C3560- Fas 0/13sw3 Fas 0/14 166 S I WS-C3560- Fas 0/13sw3 Fas 0/13 166 S I WS-C3560- Fas 0/13
seems to be a bit abnormal if you ask me. kinda what you said you saw. the same results on sw3 but i'll leave the ouput out to keep this post as short as possible.
now with three METRO vlans 100, 200 and 300 assigned on sw1 as follows:
vlan 100 for ports f0/13, f0/16vlan 200 for ports f0/14, f0/17vlan 300 for ports f0/15, f0/18
see the difference in "sh cdp neighbors" output. now looks normal.from sw2sw2(config-if-range)#do sh cdp neigh | i sw3sw3 Fas 0/15 147 S I WS-C3560- Fas 0/15sw3 Fas 0/14 147 S I WS-C3560- Fas 0/14sw3 Fas 0/13 147 S I WS-C3560- Fas 0/13
sw3(config-if-range)#do sh cdp neigh | i sw2sw2 Fas 0/15 168 S I WS-C3560- Fas 0/15sw2 Fas 0/14 168 S I WS-C3560- Fas 0/14sw2 Fas 0/13 168 S I WS-C3560- Fas 0/13
i saw the mac-add flap for bit with one METRO vlan, but after a while i never saw it again, yet the cdp output looked abnormal and nothing i tried would fix it.
these tests were done using layer 2 and layer 3 port-channels on sw2 and sw3 as well as adding a router on each end of sw2 and sw3 and providing a cdp and layer 2 path for them via the tunnel without adding a vlan, similar to lab 8 i believe.
so again, no explanations for having multiple vlans. i also didn't get a chance to reach out to IE experts, but maybe one of them will see this post and can help shed some light or clear things up for us?
i'll ping you soon on sametime
we turned out to be colleagues
Good post, glad I stumbled across this one. It seems that the task picked and chose different portions of the Metro example on the CCO. The reason for the multiple VLAN's needed is that the etherchannel is expecting a point to point connection. When all 4 ports join up in the same layer2 QinQ domain, each side of the connection can't tell which port to bond to (for lack of a better explanation). Also, a standard etherchannel is way more forgiving than LACP or in particular PaGP, which seems to be very finicky. The etherchannel will work, but it won't be optimal, PaGP just flat out will not work until the there is layer2 separation.
Here was final config this problem:
interface FastEthernet0/17 switchport access vlan 100 switchport mode dot1q-tunnel l2protocol-tunnel drop-threshold point-to-point pagp 1000 l2protocol-tunnel cdp l2protocol-tunnel point-to-point pagp no cdp enable spanning-tree bpdufilter enableendRack1SW1#sr int f0/18Building configuration...Current configuration : 261 bytes!interface FastEthernet0/18 switchport access vlan 101 switchport mode dot1q-tunnel l2protocol-tunnel drop-threshold point-to-point pagp 1000 l2protocol-tunnel cdp l2protocol-tunnel point-to-point pagp no cdp enable spanning-tree bpdufilter enable
Seems to work okay and all switch are happy.