[c-nsp] MTU on MPLS TE Tunnels w/PA-FE-TX?

[Rodney Dunn]

On Tue, Mar 20, 2007 at 11:21:02AM -0400, Vinny Abello wrote:
> Rodney Dunn wrote:
> > On Sun, Mar 18, 2007 at 11:08:49PM -0400, Vinny Abello wrote:
> >> Nope, I think what I have wrong is is I'm not running an S train or that Cisco has not put those fixes in any mainline code yet. I checked a few routers that do have SB trains and it seems to work properly although I didn't do a complete test on them yet. I need to get some time to test more in a lab scenario.
> >>
> > 
> > I've never seen a report of MPLS mtu set to 1508 to get 2 bytes of
> > labels (1 IGP + 1 VPN) not working on those PA's. You may be having a TE
> > specific problem.
> 
> Possibly... Like I said, I'm new to it, but I'm just following guides in several Cisco Press books on MPLS. Anyone feel free to make any suggestions to something obvious I'm missing. Just as an FYI, I'm currently using TDP instead of LDP due to 12.2 apparently not supporting LDP. I can switch that if this has any bearing on this problem. I just thought I'd mention it. I just want to rap my head around traffic-engineering and that's the code I'm working with currently.
>

I'm not sure exactly how that works given the tunnel could route over
any interface with various mtu sizes (say you reopt to a serial path that
can handle say a 4470 mtu).

This sounds more like an ip2tag mtu check.

In the ip2tag path I think we are supposed to fragment before mpls
encapsulation.

This sounds like a bug if it isn't working.

Can you try 12.4 mainline latest and see if it works?

 
> 
> Here is what I see on the tunnel interface which shows the missing 4 bytes due to what I am assuming is the label:
> 
> Interface Tunnel49024:
>         IP tagging not enabled
>         TSP Tunnel tagging not enabled
>         Tag Frame Relay Transport tagging not enabled
>         BGP tagging not enabled
>         Tagging operational
>         Optimum Switching Vectors:
>           IP to Tag Feature Vector
>           Tag Switching Feature Vector
>         Fast Switching Vectors:
>           IP to Tag Fast Feature Switching Vector
>           Tag Switching Feature Vector
>         MTU = 1496
>         ^^^^^^^^^^
> 
> Tunnel configuration is basically the following:
> 
> interface Tunnel49024
>  ip unnumbered Loopback0
>  tunnel destination 192.168.0.24
>  tunnel mode mpls traffic-eng
>  tunnel mpls traffic-eng path-option 10 dynamic
>  tunnel mpls traffic-eng autoroute announce
> 
> 
> Physical interface pointing to the router with loopback of 192.168.0.24 is:
> 
> interface FastEthernet3/0
>  ip address 192.168.7.101 255.255.255.252
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip router isis
>  ip route-cache flow
>  no ip mroute-cache
>  duplex full
>  mpls traffic-eng tunnels
>  tag-switching mtu 1508
>  tag-switching ip
>  no cdp enable
>  no mop enabled
>  isis hello-interval 3
> 
> 
> and the show mpls interfaces detail output for FastEthernet3/0 shows the correct MTU I set with tag-switching mtu command:
> 
> 
> Interface FastEthernet3/0:
>         IP tagging enabled
>         TSP Tunnel tagging enabled
>         Tag Frame Relay Transport tagging not enabled
>         BGP tagging not enabled
>         Tagging operational
>         Optimum Switching Vectors:
>           IP to Tag Feature Vector
>           Tag Switching Feature Vector
>         Fast Switching Vectors:
>           IP to Tag Fast Feature Switching Vector
>           Tag Switching Feature Vector
>         MTU = 1508
> 
> 
> As you can see, I have the tag-switching mtu set to 1508 currently. When I have autoroute announce set on the tunnel to inject the path into ISIS, I suddenly cannot ping 192.168.0.24 with packets of 1500 bytes unless I let them fragment. I can successfully ping with 1496 no problem. All these tests are performed from the headend router which is from where I'm showing all this configuration.
> 
> The actual Tunnel interface shows the following:
> 
> 
> Tunnel49024 is up, line protocol is up
>   Hardware is Tunnel
>   Interface is unnumbered. Using address of Loopback0 (192.168.0.49)
>   MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation TUNNEL, loopback not set
>   Keepalive not set
>   Tunnel source 192.168.0.49, destination 192.168.0.24
>   Tunnel protocol/transport Label Switching, key disabled, sequencing disabled
>   Checksumming of packets disabled,  fast tunneling enabled
>   Last input never, output never, output hang never
>   Last clearing of "show interface" counters 2d08h
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 34
>   Queueing strategy: fifo
>   Output queue: 0/0 (size/max)
>   5 minute input rate 0 bits/sec, 0 packets/sec
>   5 minute output rate 0 bits/sec, 0 packets/sec
>      0 packets input, 0 bytes, 0 no buffer
>      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>      39705 packets output, 6733402 bytes, 0 underruns
>      0 output errors, 0 collisions, 0 interface resets
>      0 output buffer failures, 0 output buffers swapped out
> 
> 
> Again, any suggestions appreciated.
> 
> router1#sh ver | i IOS
> IOS (tm) 7200 Software (C7200-JK9S-M), Version 12.2(40), RELEASE SOFTWARE (fc1)
> router1#sh ver | i image
> System image file is "disk0:c7200-jk9s-mz.122-40.bin"
> 
> 
> Actual hardware:
> 
> Slot 3:
>         Fast-ethernet (TX-ISL) Port adapter, 1 port
>         Port adapter is analyzed
>         Port adapter insertion time 5w4d ago
>         EEPROM contents at hardware discovery:
>         Hardware revision 1.4           Board revision B0
>         Serial number     15797601      Part number    73-1688-05
>         FRU Part Number:  PA-FE-TX
> 
>         Test history      0x0           RMA number     00-00-00
>         EEPROM format version 1
>         EEPROM contents (hex):
>           0x20: 01 11 01 04 00 F1 0D 61 49 06 98 05 00 00 00 00
>           0x30: 58 00 00 00 99 10 24 00 FF FF FF FF FF FF FF FF