6880-X and QinQ/Tagged traffic through EoMPLS

[fowler.david]

Hi Folks

Does anyone have a working configuration for QinQ through EoMPLS on the 6880 platform? We can't seem to get the tagged frames through the EoMPLS VC. I have noticed this caveat in the documentation:

"802.1Q in 802.1Q over EoMPLS is supported if the outgoing interface connecting to MPLS network is a port on an Layer 2 card."

Is this relevant?

Configuring the Port based EoMPLS works for L2 (CDP etc) and the native vlan from the client, but tagged VLANs simply do not pass through. This also happens if we configure VPLS instead.

Client:

interface GigabitEthernet1/0/13
 switchport trunk native vlan 999
 switchport trunk allowed vlan 1120-1139
 switchport mode trunk
end

MPLS Switch:

Client facing port

interface TenGigabitEthernet1/1/16
 no switchport
 mtu 9216
 no ip address
 load-interval 30
 no keepalive
 no cdp enable
 xconnect x.x.x.x 75 encapsulation mpls

MPLS facing port

interface TenGigabitEthernet2/5/8
 no switchport
 mtu 9216
 bandwidth 1000000
 ip address x.x.x.x 255.255.255.254
 no ip redirects
 no ip proxy-arp
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 7 xxxxxxxxxxxx
 ip ospf network point-to-point
 ip ospf cost 200
 load-interval 30
 mpls traffic-eng tunnels
 mpls ip
 bfd interval 750 min_rx 750 multiplier 3
 ip rsvp bandwidth percent 10

Any ideas?

Thanks,

David.

[Giuseppe Larosa]

Hello David,

it looks like you are hitting a platform specific issue

>> "802.1Q in 802.1Q over EoMPLS is supported if the outgoing interface connecting to MPLS network is a port on an Layer 2 card."

this sentence is no sense the core interface must be L3 enabled with LDP or RSVP TE used. try to use LDP instead of RSVP TE to the core,

Can you provide a link to the cisco document telling this?

the destination address of the xconnect must be the loopback address of the remote PE node.

with port based EoMPLS the port becomes "stupid" and allows any type of traffic.

For example I have used port based EoMPLS on ME-3600 to carry trustsec frames successfully in a recent metro ethernet project.

Hope to help

Giuseppe

[Adam Vitkovsky]

Hi,

Is the “no switchport” on the client facing port required please?

I’d Try with the following basic config first.

interface TenGigabitEthernet1/1/16

  mtu 9216

  xconnect x.x.x.x 75 encapsulation mpls

Or even better try if the 6800 can use the following modular EFP approach instead:

interface TenGigabitEthernet1/1/16

  switchport trunk allowed vlan none

  switchport mode trunk

  mtu 9216

  service instance 1 ethernet

     encapsulation default

     xconnect x.x.x.x 75 encapsulation mpls

adam

[Giuseppe Larosa]

Hello Adam,

the no switchport interface command is required if you want to perform port based EoMPLS this is true also on ME-3600 in my project.

The strange issue is that with port based EoMPLS the port is made an OSI layer1 entity that does not care about MAC address learning or used Ethertype you just need a big enough MTU to carry the Q in Q traffic over the pseudowire.

According to configuration provided by original poster the MTU is set to 9016 bytes so he shouldn't face an issue of MTU.

Port based EoMPLS is a legacy feature I have tested it the first time in 2004 on Cisco 12000 3 GE linecard. I'm afraid Cisco is going to remove this feature.

Hope to help

Giuseppe

[Adam Vitkovsky]

Just recently one engineer was complaining that Nexus 92160YC-X did break his L2 traffic over PW if the Dst MAC address in the inner Ethernet header started with 4 or 6.

So this can be something with the ASIC logic trying to do load-balancing and end up dropping the packet instead.

Maybe OP can reference Bug CSCvc33783 to see if it is a similar problem.

Yeah regarding the port based EoMPLS config. It would be nice if all platforms that do support Carrier Ethernet services where using the same EFP based approach (either using service instance or sub-interface method).

adam