The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2001-Apr> msg00125



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RE: tag-switching and MTU on c7206

  • From: "Alexander Marhold" <alexander@marhold.at>
  • Date: Wed, 25 Apr 2001 21:31:42 +0200
  • Importance: Normal
  • Resent-Date: Wed, 25 Apr 2001 17:10:51 -0400
  • To: "Venko Moyankov" <venkom@mobikom.com>, <mpls-ops@mplsrc.com>

---see inline comments

>
>From: Venko Moyankov [mailto:venkom@mobikom.com]
>Sent: Wednesday, April 25, 2001 7:35 PM
>To: mpls-ops@mplsrc.com
>Subject: tag-switching and MTU on c7206

>I started tag-swiching between two cisco 7206 VXR (IOS 12.1(6)E and
>12.1(5)E JS). The routers are connected to each other with FE interfaces
>via 3Com and cisco switches. It seems that there is problem with MTU
>path discovery if traffic goes between these two routers and
>tag-witching is enabled on FE interfaces. Some web servers are
>inaccessible e.g. mail.yahoo.com. Ping and traceroutes are ok, but http
>with large pages doesnt work.  When I stop tag-switching on FE
>interfaces everything is working fine.

--- a labelled packet is larger than 1500 , yes

>I know that LDP (TDP) calculates minimum MTU over the LSP and if packet
>is lager, it is fragmented before entering MPLS domain. So I shoudn't
>care about actual MTU on interfaces in MPLS core and labels size.

----No, No, NO
1st: there is no minimum MTU checking in LDP
2nd: 99,9% of all TCP applications have the DONT fragment bit set and use
RFC1191 PATH-MTU Discovery
they negotiate a MTU size between client and server ( as they typically sit
on an ethernet =1500)
and start sending the packet and if something goes wrong they wait for an
ICMP message telling them the next-hop path MTU size ( in our case 1496 if
there is one label)
but it seems that any router or firewall inbetween blocks that ICMP message
to the sender of the first large packet ( the server)


>Do you know if it is a IOS bug, or I have to configure differen MTU,
>when take into account interfaces MTU and label stack?

--- the only issue I am aware of is that on low-endplatforms ( 26xx and
36xx) fragmentation is not done when the unlabelled packet would fit but the
labelled one is too big and DF bit is 0 ( only normally applies to PING), so
the imposition process does not fragment. ( But that has nothing to do with
your case !)

>And one more thing: when I change tag-switching mtu on FE interfaces to
>1540 this problem seems disappear, but I really don't think it is
>correct
>to manualy set MTU on LSP.

--- this confirms my above explanation, because now the labelled link is not
a bottleneck anymore and the end-to-end negotiated MTU is okay

with best regards

Alexander

__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
     __/
    __/   Dipl.Ing. Alexander Marhold MBA
   __/   CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642
  __/   PRO IN <Senior Consultant, PM and Trainer>
 __/   Mobile: ++43-(0)664-16 28 234
__/



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml