Can you carry L3VPN MPLS packets over Ethernet XConnect?

Unanswered Question
Aug 29th, 2010
User Badges:

Hi All,


Can you carry L3VPN MPLS packets over an ethernet port-based xconnect???


Current:


POP_1 >> Physical Circuit <<  POP_2


Proposed:


POP_1 >> Provider_Router_1 << ethernet port-based xconnect >> Provider_Router_2 << POP_2


We are cancelling our physical circuits between each POP and going with another provider who is going to carry all our traffic between the POPS using ethernet xconnects. We have a few L3VPN MPLS customers and I wasn't 100% sure if their L3VPN data would be carried over the proposed xconnects.


Thanks.


Andy

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Atif Awan Sun, 08/29/2010 - 21:59
User Badges:
  • Cisco Employee,

It should work provided you run MPLS over this link :-), however, you need to account for the MTU properly. Service provider needs to support a higher mtu for your services to run transparently over this infrastructure. The exact mtu required will be sum of the SP overhead (Your ethernet header, Tunnel/VC label) of L2VPN plus your own overhead of L3VPN (labels primarily). I would highly recommend you discuss this with your SP and once they are on board do test it out in a controlled manner.


Atif

Chetan Kumar Ress Mon, 08/30/2010 - 11:57
User Badges:
  • Silver, 250 points or more

Hi Andy


As per your senario L3VPN over xconnect will work.


xconnect will give you clear P2P connectivity , So need to worry you can go head and do the POC for same but as Atif told you need to take care of MTU with you SP.


If you think all service provider don't have ther oown fiber to estabilish connectivity between all location , So for example Tier 3 & Tier 2 SP will use the existing setup of  other telecom provider to get connectivity. So in there senario they will use the same way ( Not all SP ). So your senario will work .


Regards

Chetan Kumar

http://chetanress.blogspot.com

asaykao73 Tue, 08/31/2010 - 01:41
User Badges:

Thanks guys for your reply...


One thing that I've never fully understood is the MTU setting you need within the Service Provider's core network (and I've read quite a bit about it).


For example we've cut across to the new xconnect circuit last night and I can get a 1500 byte L3VPN MPLS packet through the Service Provider's core from one PE to another PE via the xconnect (see below). I think this is made up of the payload (1492 bytes) + 2 x Tunnel/VC headers (8 bytes) = 1500 bytes total - so the Service Provider's core has MTU of 1500 bytes (correct me if I'm wrong on this).


Now I don't know if this is good or bad??? What should I be looking for? How do I determine what MTU is required through the Service Provider's core???


PE_1#ping vrf NSTEST 172.16.100.17 size 1492 df-bit

Type escape sequence to abort.
Sending 5, 1492-byte ICMP Echos to 172.16.100.17, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms


PE_1#ping vrf NSTEST 172.16.100.17 size 1493 df-bit

Type escape sequence to abort.
Sending 5, 1493-byte ICMP Echos to 172.16.100.17, timeout is 2 seconds:
Packet sent with the DF bit set

.....


Thanks.


Andy

Atif Awan Tue, 08/31/2010 - 08:26
User Badges:
  • Cisco Employee,

Regarding what MTU to choose in the SP core, well at a bare minimum it should be large enough to support all applications/services SP wants to provide over this infrastructure. From a customer perspective usually this means that a packet with a 1500 byte IP payload (IP header included) should be supported end to end without fragmentation so you can base your calculation using this as a reference point. For L3VPN this would mean 8 extra bytes (two labels) in absence of TE/FRR. For L2VPN this can potentially mean upwards of 1530 bytes depending on the Attachment Circuit type. From an SP core perspective I personally think it makes sense to set the MTU to the largest value that is consistently supported across all core interfaces and leave the customer facing links to their default MTU value unless a change is required there for special cases (customer running MPLS themselves).


In your particular case I believe the issue is the MTU setting on the interface between your PE and the SP PE. It seems like it is set to 1500 (default) which means that your own overhead will need to be accounted for within these 1500 bytes. You can ask your SP to increase the MTU on this interface at both ends of the circuit and see if this allows you to transmit full 1500 IP payload packets.


Atif

asaykao73 Wed, 09/01/2010 - 19:07
User Badges:

Hi Atif,


I've changed the MTU on the interfaces of each PE that plugs into the port based xconnect with MTU 1600. I can now ping across the SP's core with 1518 bytes (see below).


Eg: PE_1  << xconnect >> PE_2


PE_1#ping vrf NSTEST 172.16.100.7 size 1518 df-bit

Type escape sequence to abort.
Sending 5, 1518-byte ICMP Echos to 172.16.100.7, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/12 ms
agr1-ks-mel#ping vrf NSTEST 172.16.100.7 size 1518 df-bit


PE_1#ping vrf NSTEST 172.16.100.7 size 1519 df-bit

Type escape sequence to abort.
Sending 5, 1519-byte ICMP Echos to 172.16.100.7, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)


Does this mean the maximum MTU supported end to end through the SP's core is at present 1544 bytes as shown below???


Core MTU >= Edge MTU + Transport Header + AToM Header + (MPLS Label Stack *    MPLS Header Size)


Core MTU >= 1518 + 14 (transport) + 4 (control word) + 8 (2 x mpls label stack) = 1544 bytes


Thanks.


Andy

Atif Awan Thu, 09/02/2010 - 01:24
User Badges:
  • Cisco Employee,

Required MTU in core will be:


MTU = Link Header (SP Link header) + VC Overhead + Transported L2 Header (Your L2 header) +  Payload (Your payload)


In your case:


MTU = 18 or 22 bytes + 8 bytes (two labels and assuming no CW for EoMPLS) + 14 bytes (no dot1q) + 1518


Atif

Actions

This Discussion