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

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

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

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