10-06-2009 04:16 AM - edited 03-04-2019 06:16 AM
Hi
Topology:
A--DS/PE---CORE/P---ISP/PE--P---ISP/PE--B
AS per above topology,am not able to transfer files with MTU frame size above 1492 though the MTU configured on interface is 1500.The link between DS/PE---CR/PE is mpls enabled i have configured the MTU size to 1524 to carry extra labels of MPLS as recommended by cisco.
When i do extnded ping from DS/PE above MTU size of 1492 with even DF bit not set am not able to ping customer end (B),
AND also i tried with DF bit set am not able to recieve any notifications ICMP destination unreacheable messages.
The file transfer from customer B with packet size above 1492 are received by customer A but when the connection are initiated through customer A they are not.
Within an enterprise it works with larger MTU size when tried to ping from DS loopback to core loopback.How can i troubleshoot it is a problem through my end or from the ISP.
response will be appreciated
Solved! Go to Solution.
10-08-2009 08:46 PM
Hello Altaf,
from your last updates on this thread we can say:
a smaller MTU limitation is present in the other ISP network.
The customer starting a ping with size 1493 bytes receives an ICMP unreachable need to fragment sourced by ISP/PE node that is the PE node connecting to customer's site B.
A possible explanation is that Customer SiteB is connected to ISP/PE using PPPoE that has an overhead of 8 bytes leading to a max MTU of 1492 bytes for user traffic.
>> The command mpls MTU 1524 AND another command MTU 1524
the two commands do two different things:
mtu 1524 allow every protocol to increase their MTU it allows for an IP packet of size 1508 for example.
mpls mtu 1524: allows for an increase of MTU of MPLS frames.
To be noted that the second command doesn't specify how many MPLS labels should be inside the MPLS frame.
if both commands are used together an IP packet of size 1508 can be carried inside an MPLS frame with a label stack of two labels in a single frame:
1508+4+4 = 1516 size of resulting MPLS frame.
if we add ip mtu 1500 IPv4 packets cannot be greater then 1500 bytes.
Hope to help
Giuseppe
10-06-2009 04:23 AM
Hello Altaf,
the exact command you have used on the interfaces may make the difference_
have you used
mtu 1524
and
mpls mtu 1508?
or only the first one
you can check MPLS MTU with
sh mpls interface
Edit:
if you are not the provider but the customer you should stay with mtu 1500 it is the provider that needs to make changes to support user traffic.
Or is this a Carrier Supporting Carrier Scenario?
Hope to help
Giuseppe
10-06-2009 07:08 AM
Hello,
Its a carrier supporting carrier
The interface on which customer A is connected MTU is default to 1500
And the link between Distribution and core is a MPLS enabled on interfaces with mpls mtu 1524.
The link between core and ISP is back to back VRF connected via a layer 2 trunk.The ISP is creating a sub-interfaces on his 3800 router with encapsulation and vlan number.AND on Core am creating a SVI with a same vlan number and ip address within the subnet.
Each customer VRF for ex:(A) is associated with SVI virtual interface on 6500(core)and traffic is passed to customer B.On SVI the MTU is default to 1500.
BGP is routing protocol between CORE nd ISP.
ON 3800 router (ISP End)
int gig0/0
no shut
no ip add
int gig0/0.1
no shut
encapsulation dot1q 50
ip vrf forwarding XX
ip add 10.10.10.1 255.255.255.254
ON MY END (CORE)
int gig5/1
switchport trunk encapsulation dot1q
switch mode trunk
int vlan 50
ip vrf forwarding customer A
ip add 10.10.10.2 255.255.255.254.
Thanks
10-06-2009 09:49 AM
Hi,
Awaiting UR replies expert's.It's a strange issue for me.
10-06-2009 10:22 AM
Hello Altaf,
I would say this is inter-AS MPLS VPN option A with back to back links at AS border link.
However, on DS PE check how many labels are used for reaching Site B IP subnets.
use
sh mpls forw ASBR-loop-ipaddr
+
sh mpls forw vrf Customer A SiteB-ipsubnet detail
this depends on how many router hops are in your network if DS/PE is directly connected to core and core is also the ASBR you should have MPLS frames with only the VPN label for penultimate hop popping.
you should check with sh ip route vrf what is the Global Routing table next-hop for SiteB IP subnets.
it should be core= ASBR loop if you have used next-hop-self in vpnv4 address-family towards DS/PE.
check this on DS/PE
check also what happens when trying to ping:
From DS/PE VRF access link to ISP/PE link in VRF use extended ping in VRF for this.
also posting more complete configs and the shows described above could help because it is a strange issue.
Also if there is a LAN switch in the middle between DS/PE and core switch you need to increase MTU on it too.
This is sometimes overlooked.
Hope to help
Giuseppe
10-06-2009 11:17 AM
Hello,
DS/PE is a 6500 switch and it is directly connected to Core,and Core is the ASBR connected to ISP.
When i do sh ip route VRF the next-hop for customer B routes is the loopback address of CORE (ASBR)
The normal ping till MTU 1492 get's success but after 1492 the success rate is 0%,
Customer complaints that TCP files transfered from B to A with MTU 1500 has no problem but from A to B it can't above 1492. He says that the problem is with the customer carrier not with the backbone carrier.
How the above para can be possible,traffic is passsing through the same interface as such what it is passing from to A to B.
10-06-2009 11:44 AM
Hello,
Though i have a RR connected to my core and RR is peering MPBGP with core and DS,but also my DS and core are directly connected so it does'nt make such difference for presence of ip next-hopself on core as my all loopback are advertised in IGP (OSPF,
One thing to highlight mine core and DS are connected via a 10gig X2 module.
help is appreciated.
10-06-2009 11:57 AM
Hello Altaf,
if the BGP next-hop is the core/ASBR router this is fine.
being an inter-AS MPLS VPN scenario the problem can be on the other side/provider.
try to use debug mpls packets
and debug ip icmp to see if you are sending the packets to your neighbor.
you can also use an ACL applied to SVI on core/ASBR router
in this way you can understand what is the max size of packets you are able to send to the other provider.
if you see you are correctly sending ICMP requests to the other provider but you don't see icmp replies coming back you have something to talk with the other provider.
Hope to help
Giuseppe
10-06-2009 12:17 PM
Hello,
The ping with MTU 1492 is successful 100% but as if when i changed the MTU to 1493 the success is 0%.
i have enable debug ip icmp packets the replies are fine with DS/PE as a source and a customer B as a destination.
The customer says that the next hop to core that means ISP/PE is intimating him âicmp: 10.X.X.X unreachable - need to frag (mtu 1492)â. But not my core nor my DS.WHY????
10-06-2009 12:26 PM
hello
can u please.
When a customer is trying to send larger MTU size the next hop to core notifies him âicmp: 10.X.X.X unreachable - need to frag (mtu 1492)âbut not my core nor my DS notifies him.
10-08-2009 01:05 PM
Hi,
Is it 2 command acts differerent by confiuration on interface.
The command mpls MTU 1524 AND another command MTU 1524
10-08-2009 08:46 PM
Hello Altaf,
from your last updates on this thread we can say:
a smaller MTU limitation is present in the other ISP network.
The customer starting a ping with size 1493 bytes receives an ICMP unreachable need to fragment sourced by ISP/PE node that is the PE node connecting to customer's site B.
A possible explanation is that Customer SiteB is connected to ISP/PE using PPPoE that has an overhead of 8 bytes leading to a max MTU of 1492 bytes for user traffic.
>> The command mpls MTU 1524 AND another command MTU 1524
the two commands do two different things:
mtu 1524 allow every protocol to increase their MTU it allows for an IP packet of size 1508 for example.
mpls mtu 1524: allows for an increase of MTU of MPLS frames.
To be noted that the second command doesn't specify how many MPLS labels should be inside the MPLS frame.
if both commands are used together an IP packet of size 1508 can be carried inside an MPLS frame with a label stack of two labels in a single frame:
1508+4+4 = 1516 size of resulting MPLS frame.
if we add ip mtu 1500 IPv4 packets cannot be greater then 1500 bytes.
Hope to help
Giuseppe
10-08-2009 10:47 PM
Hey Dear,
I changed the command on the link between DS and Core from mpls mtu 1524 to mtu 1524 the packet are being tranfered till the ISP/PE the next hop from my core but after that it gets dropped,the issue is not from my end.
Thanks a tons for back to back response.
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: