From: sabrina pittarel (sabri_esame@yahoo.com)
Date: Wed Dec 20 2006 - 03:40:17 ART
Hi Jay,
what a dot1qtunnel interface allows you to do is just to add an
additional dot1q tag (outer dot1q "S-tag" or SP tag) to traffic sent from the
customer network into the server provider network.
What you accomplish doing
that is: you hide the original tag (i.e. the vlan membership) of the customer
traffic while it is travelling inside the service provider network. The
Service Provider network will see that traffic as belonging to the S-vlan that
the provider assigned to that customer.
The original tag (inner dot1q "C-tag"
or customer tag) will re-emerge only once the frame has reached the remote
customer site, where an "egress" dot1q tunnel interface will take care of
stripping the outer S-tag.
In all this we have not manipulated at all the
original mac addresses (remember that the dot1q tag is inserted after the MAC
SA address), so learning will happen on those. What you should see though is
that learning happens on the S-vlan and not on the original vlan the traffic
belonged to while in the customer network.
802.1ah aka MTP (Mac Tunnelling
Protocol) aka MacInMac is the IEEE standard that allows the *entire* customer
frame to be encapsulated in another L2 layer (decided by the Service
Provider), hence masking the original customer MAC addresses and preventing
any learning to happen on those in the SP network.
802.1ah is a quite new
standard and networking equipment vendors are still trying to catch up
Sabrina
----- Original Message ----
From: jay buss <ccie_sp@hotmail.com>
To: ccielab@groupstudy.com
Sent: Tuesday, December 19, 2006 9:34:09 PM
Subject: Dot1q-tunnel, many customer mac-addresses in SP cloud
Hi,
100mac-addresses(customerswitch)<--->dot1qtunnel(SPswitch)<--->(SPswitch"all-
mac-addresses")<-->(SPSWITCH)dot1qtunnel<-->100mac-addresses(customerswitch)
Again regarding the mac-addresses received from a customer connected behind a
dot1q tunnel, I see ALL the mac-addresses from that customer in the SP core
switches.. Actually this behaviour looks like that the SP switch is connected
to the customer via a normal trunk and via that way receives all mac-addresses
from the customer, is this normal behaviour for dot1q-tunneling???? If so.. I
thought the SP would be transparent to the customer, but I see that the
customers are not transparent to the SP..Now I see that all mac-addresses from
that customer are in the SP switches, what's common practice to reduce this,
and if this is normal behaviour, then this looks like a NOT very scalable
solution.. Or is there something that I'm missing? Help is appreciated to
understand this topic.. thanks
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:38 ART