10-07-2009 05:01 AM - edited 03-06-2019 08:01 AM
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.
10-07-2009 07:42 AM
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
10-07-2009 01:47 PM
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
10-07-2009 01:55 PM
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
10-07-2009 02:26 PM
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.
10-09-2009 08:35 AM
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.
10-09-2009 08:49 AM
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.
10-08-2009 06:19 PM
Try the "l2protocol" command interfaces.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide