09-24-2006 12:00 AM
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
09-24-2006 10:25 AM
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.
09-24-2006 08:49 PM
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
09-25-2006 03:08 AM
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
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
09-25-2006 05:09 AM
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.
09-25-2006 12:15 PM
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
09-25-2006 01:17 PM
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
09-26-2006 12:26 PM
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
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