cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1643
Views
18
Helpful
7
Replies

MTU Ethernet MPLS Network

jackharo46
Level 1
Level 1

Actually I have implemented MPLS in my Ethernet network using Cisco 75XX as part of my core (P) and Huawei equipments for access (PE). We realized that customers can not navigate to certain pages like hotmail, msn, hi5, etc. Reviewing possible solutions we found two options:

- Change the MTU 1492 in the CE equipment

- Adjust TCP MSS size to 1440 in CE.

Making this our customers finished complianing. Besides this all interface working under MPLS are using MPLS MTU 1508 command but Huawei PE?s dont support a similar command.

My question is what is the real effect of mpls mtu command? is it change the mtu size for predefined Ethernet??

Do you have any suggestion or similar cases, to make "transparent" for customes transition to MPLS network and not change values in CE equipment??

I really appreciate your answers and sugestions,

Best Regards

Jack

7 Replies 7

swaroop.potdar
Level 7
Level 7

Hi Jack,

////////////////////////////////

1) Why a Datagram is Fragmented:

When a frame is carrying an unlabeled IP datagram, the Frame

Payload is just the IP datagram itself. When a frame is

carrying a labeled IP datagram, the Frame Payload consists of

the label stack entries and the IP datagram.

Now when this frame payload as defined as above exceeds the

conventional layer 2 media MTU then the frame is fragmented.

In case of ethernet this MTU is 1500.

So for example when a unlabelled frame with payload of 1500

bytes is received and the same has to be sent further to

the remote destination by labelling it, then the payload

has to be fragmented.

///////////////////////////

2) Why the MPLS MTU command:

Once you receive an unlabelled frame, first the PE router

receives it, labels it and then its put out for forwarding,

when its to be forwarded, it needs to be fragmented.

The problem comes here, when before being forwarded out of

the interface if it gets fragmented, it would create two

fragments or frames.

By conventional fragmentation, the label which is inserted

in the header may not be preserved into the new fragments

created and the frame may be simply discarded as it loses

the forwarding address which was the label.

So to avoid this MPLS MTU command needs to be configured,

so when there is fragmentation, it takes care of putting

in the same label into the fragments created.

Now in IOS even is MPLS MTU command is not configured

it takes the default MTU as the MPLS MTU value.

///////////////////////////

3) Solution to your problem:

To aviod configuring the CE devices with MTU 1492,

what you need to take care of is configure all you

core facings links, with an physical MTU of 1508.

So automatically your TCP packets which if total

to 1500 bytes payload with a DF bit set wont need

to be fragmented from PE at one end to other end.

For this your PE <--->P link ethernet media MTU

should be 1508, (if you can configure 1512 or 1516

that would also be great if you plan to increase the

stack size or later provide IPV6 VPN's.)

You P<-->P links ethernet media MTU should also be

the same as set between PE to P. if you have any

SONET/POS links in your backbone then you dont have

to do anything for the MTU.

So the net effect of this would be any TCP sessions

as which are prone to setting the DF bit can be

transparently sent across without send ICMP error message.

HTH-Cheers!

Swaroop

You may also like to see the RFC 3032 about label stack.

Very clear Swaroop. But when I try change physicak MTU value on Cisco 75XX I received the following:

===========================================

interface FastEthernet0/0/0

description CONEXION XXXXX

ip address XX.XX.XXX.XX XXX.255.255.XXX

full-duplex

tag-switching mtu 1508

tag-switching ip

DIV-CORE-RTR1(config)#int fa0/0/0

DIV-CORE-RTR1(config-if)#mtu ?

<64-4294967295> MTU size in bytes

DIV-CORE-RTR1(config-if)#mtu 1512

% Interface FastEthernet0/0/0 does not support user settable mtu.

DIV-CORE-RTR1(config-if)#

===========================================

In accord to this I can?not change the interface MTU do you have some suggestion to this??

I have another doubt, actually I have configured 01 FastEthernet interface with many secondary IP address and MPLS enabled. When some host coming by MPLS try to connect other host (non MPLS) connected to a secondary IP network, do it will take the process of strippe MPLS label and forward on the same interface without MPLS label??. Is it any issue for secondary IP address in the same interface??

I apreciate your time and answer.

Best regards

Hi Jack,

Two things,

1) You can check for HW/SW support on 7500 for Jumbo MTU Support. SO you can achieve the desired solution for your problem.

2) Issue this command "show ip cef detail"

this would give you the answer whether it goes with a MPLS label or wothout a label.

Have never experiemented such a scenario, but i believe for a Non-MPLS destination you wont send a label. As the bindings for Non-MPLS system prefixes would be generated till the last hop, till where MPLS is enabled.

Verify it using the above command and pls confirm.

HTH-Cheers,

Swaroop

few things here - you have already set the mtu for mpls on your 7500's to 1508 with the command tag-switching mtu so thats ok. What is the MTU on the Huwaei interfaces by default? Surely you must be able to set mtu on the Huwaei devices to whatever. You may also find that the mtu on certain interfaces for Huwaei are 4470 in which case you really are stuffed if you cant change them. One law of MPLS is the MTU at the edge MUST be smaller or the same as that in the middle.

OK I have an observation about this. I reduced the MTU value to 1488 in one PE as a test directly conected to Cisco 75XX. After a while a I had the same error (No navigation to certain pages hotmail, hi5, etc). On my MPLS Huawei PEs I have no option to increase the MTU there says a maximum of 1500.

Besides this I check my cef table and its true Cisco 75xx dont tag packets to non-mpls destinations even when the origin is an MPLS interface and have to remove the tag itself.

=============================================

NON MPLS DESTINATION:

rAm-Per-Internet#sh ip cef 200.31.96.13 det

200.31.96.13/32, version 745080, epoch 0, connected, cached adjacency 200.31.96.

13

0 packets, 0 bytes

via 200.31.96.13, FastEthernet1/1/0, 0 dependencies

next hop 200.31.96.13, FastEthernet1/1/0

valid cached adjacency

rAm-Per-Internet#

=============================================

MPLS DESTINATION:

=============================================

rAm-Per-Internet#sh ip cef 200.31.115.112 det

200.31.115.112/29, version 780934, epoch 0, cached adjacency 200.31.96.251

0 packets, 0 bytes

tag information set

local tag: 763

fast tag rewrite with Fa1/1/0, 200.31.96.251, tags imposed: {47}

via 200.31.96.251, FastEthernet1/1/0, 0 dependencies

next hop 200.31.96.251, FastEthernet1/1/0

valid cached adjacency

tag rewrite with Fa1/1/0, 200.31.96.251, tags imposed: {47}

rAm-Per-Internet#

It apparently works fine, but I dont understand why I get some claims from customers conected to PE saying cannot open mail from the destination network in the same interface.

thank you for the sugestions.

Jack

Since you tried changing the PHY MTU to a lesser value you must have got it that you need a higher PHY MTU than 1500 to support end customer who generally will use max MTU of 1500. Sp Jumbo MTU support is required as inherently ethernet would have a MTU of 1500.

Most of devices I know with current IOS support MTU more than 1500(7200,7600 GSR's)

So you need to check as I have recommended earlier for Jumbo MTU support on 7500 and which interface types, and also with Huawei for MTU configuration. As the PE-P link also should have MTU larger that 1500.

FOr the secondary IP thing its very important to understand why you have deployed it in such a fashion, and also without knowing the data flow path and topology its difficult to answer why customers are not able to access non= mpls destination.

If your original post has been answered you can close this thread. and put in you new query under a different subject, that would be helpful for people having a similar issue as well.

HTH-Cheers,

Swaroop

I was looking for Jumbo support for PA-FE-TX installed in Cisco 7507 and 7513 with IOS Version 12.2(15)T17 but i cannot find anything about that, somebody know something about this.?

Thanks