[c-nsp] Cisco Nexus as MetroE switch?

Marian Ďurkovič md at bts.sk
Wed Nov 4 03:23:44 EST 2015


On Tue, 3 Nov 2015 22:33:10 +0000, Tom Hill wrote
> > TRILL switch supports QinQ just fine. If the E-LINE customer wants to use 
> > its own VLAN tags, he will just send tagged packets to TRILL switch, which
> > will add a second tag and then encapsulates the frame into TRILL container. 
> 
> Oh sure, this is fine if you're happy with QinQ levels of
> "encapsulation" for E-LINE services, but then it's down to the vendor 
> to do L2PT as they see fit. This is where just double-tagging for E-
> LINE gets horrid, especially in carrier-on-carrier situations.

In fact, QinQ is only used on customer-facing ports. Ingress TRILL switch
encapsulates received single or double VLAN tagged packets into TRILL
container - i.e. it adds TRILL header and another MAC header. Thus when the
packet travels via TRILL infrastructure, it's no longer a QinQ packet but
a fully encapsulated packet. 

TRILL container is basicaly optimised IP container, and all packet forwarding
in TRILL core is performed the same way as IP routing. Therefore, core switches
don't learn customer's MAC addresses (in contrast to native QinQ setups).

On Tue, 3 Nov 2015 13:33:51 +0000, Adam Vitkovsky wrote
> To me it's like building a Frame-Relay backbone, we've been there and 
> learned it's better to build L3 backbones over which we can build 
> virtual overlays and transport L2/L3/CEoP/SAToP/whatever else future 
> brings right?

As explained above, TRILL *is* internally using L3 backbone to transport
ethernet packets. This is way different than Flame-Delay offered.


   With kind regards,

      M.


More information about the cisco-nsp mailing list