MPLS-TE CBTS Master tunnel MTU

[Roman E]

Hello

We implement MPLS-TE with class-based tunnel selection in out network and face a problem with mpls mtu at master tunnel. All interfaces and MPLS tunnels have MTU greater than 1516, but master tunnel always has 1496.

sh run int tun1111
interface Tunnel1111
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 1.1.1.1
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 10 dynamic
 tunnel mpls traffic-eng exp-bundle master
 tunnel mpls traffic-eng exp-bundle member Tunnel1
 tunnel mpls traffic-eng exp-bundle member Tunnel11
 no routing dynamic

sh mpls interfaces tun1111 detail 
Interface Tunnel1111:
 MPLS TE Tunnel Head
 IP labeling not enabled
 LSP Tunnel labeling not enabled
 IP FRR labeling not enabled
 BGP labeling not enabled
 MPLS operational
 MTU = 1496

sh mpls traffic-eng tunnels tun1111 brief 
Signalling Summary:
 LSP Tunnels Process: running
 Passive LSP Listener: running
 RSVP Process: running
 Forwarding: enabled
 Periodic reoptimization: every 3600 seconds, next in 2615 seconds
 Periodic FRR Promotion: Not Running
 Periodic auto-bw collection: every 300 seconds, next in 215 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
PE2_t1111     1.1.1.1     -   unknown    up/up 

I can't change ip mtu or mpls mtu on tunnel interface, and  I can see  that this tunnel doesn't depent on real interface, changing mpls mtu on real interface can influence only on MPLS member tunnels, but master tunnel always has 1496.
Is there any way to change master tunnel mtu value?

We use Cisco 3945, C3900e-UNIVERSALK9_NPE-M, Version 15.3(3)M

[Yongyu Jia]

Hello,

Any reason to change that? As my understanding is the master tunnel in CBTS is just a logical pointer rather the real data plane forwarding interface (the member tunnel is).

Thanks,

[Roman E]

When we implemented master tunnel, mtu between our branches became equal of mtu of master tunnel, we found out it because we got trouble with software, which uses encrypted traffic.
When we disabled CBTS and master tunnel and were working throught simple mpls tunnel, mtu equals of mtu of this tunnel and we can change it, it depends on mpls mtu of real phisical interface
if we look at output of sh mpls traffic-eng tunnels brief command we will see:

TUNNEL NAME     DESTINATION  UP IF     DOWN IF   STATE/PROT
router-1_t110   10.10.10.21    -       Gi0/0.1      up/up 
router-1_t120   10.10.10.21    -       Gi0/0.1      up/up 
router-1_t170   10.10.10.21    -       Gi0/0.1      up/up 
router-1_t200   10.10.10.21    -       unknown      up/up 

(t200 is master tunnel)

MTU of tunnel interface depends on mtu value of phisical interface which is "down if" in our case. we have Gi0/0.1 with :

mtu 1550
ip mtu 1520
mpls mtu 1532

mtu for Tunnel110:

router-1#sh mpls interfaces tunnel 110 detail 
Interface Tunnel110:
MPLS TE Tunnel Head
IP labeling not enabled
LSP Tunnel labeling not enabled
IP FRR labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1528

and for master tunnel 200:

router-1#sh mpls interfaces tunnel 200 detail 
Interface Tunnel200:
MPLS TE Tunnel Head
IP labeling not enabled
LSP Tunnel labeling not enabled
IP FRR labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1496

And the real mtu between our routers with enabled master tunnel is 1496 (we use ping with set df bit to find out it). Master tunnel doesn't have any down interface, so we cant influent on it with changing mpls mtu of real interface. There are no any routers between router-1 and router from tunnel destination, they are directly connected in our case.

And our question is How to change master tunnel mtu value? There aae any ways to do it? or this value is hardcoded?

[Yongyu Jia]

Hi Roman,

To the best of my knowledge, MTU on the master tunnel interface is fixed.

The only potential issue I could see is for the traffic generating/desalinated from/on the routers themselves as the master tunnel interfaces are used on control plane.

Maybe the software issue you mentioned falls into that scope?

If so, I suggest to open a TAC case for the further investigation with Cisco.

HTHs,