Port-based EoMPLS not passing some protocols

Unanswered Question
Oct 7th, 2009

I am running 2 6509 with SUP720 10G supervisors running 12.2(33)SXI2a. I have configured two sides of a MPLS cloud for port-based EoMPLS via interface command:

xconnect loopbackip vcid encapsulation mpls

This works well for IP and STP traffic, but CDP, LACP, and UDLD are not working across this pwire, any hints on any configurations to try? LACP and UDLD are very much desired as I am looking to connect several of these for redundancy.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Giuseppe Larosa Wed, 10/07/2009 - 07:42

Hello Jonathan,

are you using port based EoMPLS to transport 802.1Q in Q or you have there directly a L2 trunk.

The fact that CDP, LACP and UDLD are not carried in first case would depend from missing layer2 tunneling protocol on 802.1Q tunnel port.

I mean if your scenario is:

CE device -- 802.1Q tunnel L2 PE --- l2 trunk --- EoMPLS port based --- C7600

the port based EoMPLS can only propagate what the 802.1Q tunnel is propagating.

EoMPLS should be blind and be satisfied by any 802.1Q frame that passes the CRC test.

Hope to help

Giuseppe

Edison Ortiz Wed, 10/07/2009 - 13:47

Please post the following information:

At the CEs,

sh spanning-tree int [x/x] detail

sh cdp interface [x/x]

sh run interface [x/x]

the interface should be the one facing the PE

At the PEs,

show mpls l2 vc [x] detail

show run interface [x/x]

interface information facing the CE.

Regards,

__

Edison

zztopping Wed, 10/07/2009 - 13:55

The CE is a 3750 on one end, 3750E on the other.

3750---6k----MPLS----6k---3750e

Commands are CE port facing PE and PE port facing CE.

PE:

Local interface: Gi7/1 up, line protocol up, Ethernet up

Destination address: 10.0.6.80, VC ID: 80, VC status: up

Output interface: Tu0, imposed label stack {44}

Preferred path: not configured

Default path: active

Next hop: point2point

Create time: 23:36:14, last status change time: 23:35:44

Signaling protocol: LDP, peer 10.0.6.80:0 up

Targeted Hello: 10.0.6.64(LDP Id) -> 10.0.6.80

MPLS VC labels: local 48, remote 44

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Remote interface description:

Sequencing: receive disabled, send disabled

VC statistics:

packet totals: receive 92701, send 8493

byte totals: receive 6977492, send 577604

packet drops: receive 0, send 27866

interface GigabitEthernet7/1

description PWIRE TEST PORT

no ip address

xconnect 10.0.6.80 80 encapsulation mpls

end

CE:

STP Detail:

Port 1 (GigabitEthernet1/0/1) of VLAN0005 is root forwarding

Port path cost 4, Port priority 128, Port Identifier 128.1.

Designated root has priority 32773, address 0008.e3ff.fc50

Designated bridge has priority 32773, address 0025.45e4.5580

Designated port id is 128.55, designated path cost 3

Timers: message age 16, forward delay 0, hold 0

Number of transitions to forwarding state: 1

Link type is point-to-point by default

BPDU: sent 7, received 42165

Port 1 (GigabitEthernet1/0/1) of VLAN0006 is root forwarding

Port path cost 4, Port priority 128, Port Identifier 128.1.

Designated root has priority 32774, address 0008.e3ff.fc50

Designated bridge has priority 32774, address 0025.45e4.5580

Designated port id is 128.55, designated path cost 3

Timers: message age 16, forward delay 0, hold 0

Number of transitions to forwarding state: 1

Link type is point-to-point by default

BPDU: sent 7, received 42165

CDP:

GigabitEthernet1/0/1 is up, line protocol is up

Encapsulation ARPA

Sending CDP packets every 60 seconds

Holdtime is 180 seconds

interface config:

int gi1/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 5,6

switchport mode trunk

switchport nonegotiate

udld port aggressive

Edison Ortiz Wed, 10/07/2009 - 14:26

Can you do the same commands on the remote PE and CE? I also want to see the show cdp ne interface command.

I ran into a bug on SXH1 where EoMPLS was dropping L2 control traffic but in your case some L2 control traffic is working.

If your configuration looks after posting, I will have to recommend opening a ticket with TAC for them to reproduce and file a bug against SXI2a if necessary.

UDLD, LACP and CDP should work over EoMPLS.

__

Edison.

zztopping Fri, 10/09/2009 - 08:35

Sure enough. STP root has changed. See attachment for all info in one snapshot(PE/CE output from sides of the cloud).

To answer the other comment about issuing the l2protocol config lines...I dont think that is necessary here(for EoMPLS, it seems to be a Q-in-Q feature), but can you elaborate if I'm mistaken?

I'm leaning toward that this is a bug, and the 6ks are intercepting some of these L2 protocols instead of tunnelling them as they should.

Edison Ortiz Fri, 10/09/2009 - 08:49

I tend to agree you are facing a bug - look a the counters on BPDU at both CEs, they don't correlate.

You are correct on the l2protocol assessment, you don't need that type of configuration with EoMPLS.

Open a TAC case and let us know the outcome.

Regards

Edison.

Actions

This Discussion