cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
635
Views
5
Helpful
7
Replies

MPLS L2 VPN Issue with df-bit

Muhammad Uzair
Level 1
Level 1

Hi all, hope you are doing well.

I have a very strange issue and puzzle if someone can help me as it have taken my 2 weeks but still I am back to square 1.

we are providing connectivity to 1 cutsomer which involves our 1 CPE and other CPE is provided by second provider at B end, we are responsible to provide them 1500 bytes with df-bit and it was working fine with our provider Microwave link, we decicded to shift this link from Microwave to their WLA link (through fiber) as Microwave had some issues, now the problem is we had 2 circuits 1 is working fine with same setup (maybe there is no additional header from customer) but second one having BGP flaps after this setup, when we checked the MTU it was not crossing 1500 in our provider network, they made some changes and now it is reaching 1530 from our PE to their PE but from my CPE side A to provide CPE at B side is not crossing 1496, below are the results I have tested so far.

(1) My CPE side A to my first PE (1500 reachable with df-bit) I made this testing by creating SVI (on layer 2 CPE switch and sub-interface on first PE) 

(2) My PE1 to PE2 (1500 reachable with df-bit) I checked this with my layer 3 connectivity between PE to PE and it is working perfect as MPLS is there and also jumbo frame size.

(3) My PE2 to CPE side B (1500 reachable with df-bit) I removed xconnect and put IP to make this test and it is working perfect.

(4) My CPE side A to CPE side B (1496 reachable with df-bit) we asked provide to give 1 ip of /30 and made this test but not reaching 1497.

I checked through MAC-LOOKUP provide is using D-LINK and we are using CISCO 2960S as CPE, is it okay? if any issue due to this then why pinging from other cisco 2800 series router?

Thanks in advance.

Kindly advise if this case need to be open on some other place so I will proceed accordingly.

Kindest Regards,

Uzair



Kindest regards,
Uzair
CCENT, CCNA (R&S), CCNP (R&S).
7 Replies 7

Adam Vitkovsky
Level 3
Level 3

Hi,

 

On point 2) in your case you need to be able to perform mpls ping with at least 1504.

This is because when you perform simple mpls ping between PE loopbacks, then the only mpls label in the label stack imposed on the packet (by the ingress PE) is only the next-hop label – this label will be used to deliver the packet to remote PE.

But when packet is traveling within the pseudowire/virtual-circuit, then the label stack imposed on the packet consists of two labels, the top one is the transport label from previous case and below it at the bottom of the stack is the VC(virtual-circuit) label that will be used by the egress PE to associate the incoming packet with a particular egress interface.

 

So when testing the MPLS core MTU you need to account for this VC label (additional 4B).

 

 

adam

adam

Dear adam, thanks for reply, yes I am able to reach from PE to PE with 1504, even its reaching 1540 without any issue from PE to PE.

Kindly advise if anything further need  to be checked?



Kindest regards,
Uzair
CCENT, CCNA (R&S), CCNP (R&S).

appreciate if someone can help me on this please.

Thank you.

Kindest Regards,

Uzair



Kindest regards,
Uzair
CCENT, CCNA (R&S), CCNP (R&S).

Hello Uzair,

>> but second one having BGP flaps after this setup

use QoS and and an output service policy to protect the BGP session, the BGP flaps if no BGP keepalives or other BGP messages are missed three in a row with default timer settings.

The modern way is to use standarg BGP timers + BFD to gain fast convergence.

Hope to help

Giuseppe

When you perform cmd: show mpls l2transport vc <id> detail

What is the MTU on local and remote side please?

 

adam

adam

Local interface: Gi0/3/0.1901 up, line protocol up, Eth VLAN 1901 up
Destination address: 80.95.x.x, VC ID: 231, VC status: up
Next hop: 80.95.x.x
Output interface: Gi0/2/0, imposed label stack {716 157}
Create time: 2d08h, last status change time: 2d08h
Signaling protocol: LDP, peer 80.95.x.x:0 up
MPLS VC labels: local 110, remote 157
Group ID: local 0, remote 0
MTU: local 1550, remote 1550
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 101098, send 51
byte totals: receive 7302078, send 26298
packet drops: receive 0, seq error 0, send 0

Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi0/3/0.1902 Eth VLAN 1902 80.95.x.x 221 UP
Gi0/3/0.1901 Eth VLAN 1901 80.95.x.x 231 UP

Kindest Regards,

Uzair



Kindest regards,
Uzair
CCENT, CCNA (R&S), CCNP (R&S).

Ok looks like the backbone is ok and the CE facing interfaces on both PEs are configured with MTU 1550

Then the MTU problem has to be in one of the CE-PE links.

When you test it you have to preserve the same VLAN encapsulation that is used then the CE-PE link is used as L2 link to a PW.

For example if you pin between PE and CE but it’s just untagged frame followed by IP then 1500B packet might pass through.

But then when you change the PE-CE link encapsulation to a trunk port and frames are being tagged then all of a sudden these 4B used for VLAN tag will prevent you from using 1500B frames end-to end.

 

adam  

adam
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: