Mailing List Archive

[nsp] ospf over tunnels
I've got remote site 1 on a DS3 with MTU 4470
and remote site 2 on a fastethernet with MTU 1500.

I have a GRE tunnel between them, with a cisco7206vxr
on each end, 12.0(21)S on each router.

I can't run ospf between the two because of this:

Sep 11 10:35:46: OSPF: Rcv DBD from x.y.z.w on Tunnel0 seq 0x8C9 opt 0x42 flag 0x7 len 32 mtu 4446 state EXSTART
Sep 11 10:35:46: OSPF: Nbr x.y.z.w has larger interface MTU

Cisco (http://www.cisco.com/warp/public/104/12.html) basically
says "tough luck", and contains this gem

Since the problem is caused by mismatched MTUs, the solution is to
change either router's MTU to match the neighbor's MTU. Note that
Cisco IOS doesn't support changing the physical MTU on a LAN interface
(such as Ethernet or Token Ring). When the problem occurs between a
Cisco router and another vendor's router over LAN media, adjust the
MTU on the OTHER VENDOR'S ROUTER.

(upper-case is my editing).

Any suggestions?

If I change the MTU on my DS3 to 1500 then what happens
to the 1514 MTU on the tunnel?

Thanks,
-mark
Re: [nsp] ospf over tunnels [ In reply to ]
On Wed, 11 Sep 2002 10:43:20 -0700 (PDT) Mark Kent <mark@noc.mainstreet.net> wrote:
> I've got remote site 1 on a DS3 with MTU 4470
> and remote site 2 on a fastethernet with MTU 1500.
>
> I have a GRE tunnel between them, with a cisco7206vxr
> on each end, 12.0(21)S on each router.
>
> I can't run ospf between the two because of this:
>
> Sep 11 10:35:46: OSPF: Rcv DBD from x.y.z.w on Tunnel0 seq 0x8C9 opt
> 0x42 flag 0x7 len 32 mtu 4446 state EXSTART
> Sep 11 10:35:46: OSPF: Nbr x.y.z.w has larger interface MTU
[snip]
> If I change the MTU on my DS3 to 1500 then what happens
> to the 1514 MTU on the tunnel?

It's the MTU on the tunnel interface that's the problem, not the MTU on the
physical interfaces. Set the MTU on both tunnels to be the same and it
should work.

--
Ryan O'Connell
Mail: ryan@complicity.co.uk
CV: http://www.complicity.co.uk/ryancv.pdf
CCIE #8174
RE: [nsp] ospf over tunnels [ In reply to ]
Mark,

What about ip ospf mtu-ignore (under interface configuration) ?

Regards,

Luciano

-----Mensaje original-----
De: cisco-nsp-admin@puck.nether.net
[mailto:cisco-nsp-admin@puck.nether.net]En nombre de Mark Kent
Enviado el: MiƩrcoles, 11 de Septiembre de 2002 02:43 p.m.
Para: cisco-nsp@puck.nether.net
Asunto: [nsp] ospf over tunnels


I've got remote site 1 on a DS3 with MTU 4470
and remote site 2 on a fastethernet with MTU 1500.

I have a GRE tunnel between them, with a cisco7206vxr
on each end, 12.0(21)S on each router.

I can't run ospf between the two because of this:

Sep 11 10:35:46: OSPF: Rcv DBD from x.y.z.w on Tunnel0 seq 0x8C9 opt 0x42
flag 0x7 len 32 mtu 4446 state EXSTART
Sep 11 10:35:46: OSPF: Nbr x.y.z.w has larger interface MTU

Cisco (http://www.cisco.com/warp/public/104/12.html) basically
says "tough luck", and contains this gem

Since the problem is caused by mismatched MTUs, the solution is to
change either router's MTU to match the neighbor's MTU. Note that
Cisco IOS doesn't support changing the physical MTU on a LAN interface
(such as Ethernet or Token Ring). When the problem occurs between a
Cisco router and another vendor's router over LAN media, adjust the
MTU on the OTHER VENDOR'S ROUTER.

(upper-case is my editing).

Any suggestions?

If I change the MTU on my DS3 to 1500 then what happens
to the 1514 MTU on the tunnel?

Thanks,
-mark
_______________________________________________
cisco-nsp mailing list real_name)s@puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [nsp] ospf over tunnels [ In reply to ]
>> It's the MTU on the tunnel interface that's the problem, not the
>> MTU on the physical interfaces. Set the MTU on both tunnels to be
>> the same and it should work.

I don't think so, this is what I have:

telehouse#sh in tu0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: tunnel to AN0 router in AboveNet
Internet address is x.y.z.254/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255

an0#sh in tu0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: tunnel to WCG in Telehouse
Internet address is x.y.z.253/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255

And I cannot set the MTU on the tunnel:

an0#conf t
an0(config)#in tu0
an0(config-if)#mtu 1460
% Interface Tunnel0 does not support adjustable maximum datagram size

-mark
Re: [nsp] ospf over tunnels [ In reply to ]
On Wed, 11 Sep 2002 11:07:57 -0700 (PDT) Mark Kent <mark@noc.mainstreet.net> wrote:
[snip]
> And I cannot set the MTU on the tunnel:
>
> an0#conf t
> an0(config)#in tu0
> an0(config-if)#mtu 1460
> % Interface Tunnel0 does not support adjustable maximum datagram size

Use "ip mtu" not "mtu"

--
Ryan O'Connell
Mail: ryan@complicity.co.uk
CV: http://www.complicity.co.uk/ryancv.pdf
CCIE #8174
Re: [nsp] ospf over tunnels [ In reply to ]
>> What about ip ospf mtu-ignore (under interface configuration) ?

Not in 12.0(21)S, released in 12.1(3).

Changing IOS version could open a whole new can of worms.

Thanks,
-mark
Re: [nsp] ospf over tunnels [ In reply to ]
>> Use "ip mtu" not "mtu"

I'm ringing a bell of thanks for you.
-mark
Re: [nsp] ospf over tunnels [ In reply to ]
On Wed, 11 Sep 2002, Mark Kent wrote:

> Date: Wed, 11 Sep 2002 10:43:20 -0700 (PDT)
>
> I've got remote site 1 on a DS3 with MTU 4470
> and remote site 2 on a fastethernet with MTU 1500.
>
> I have a GRE tunnel between them, with a cisco7206vxr
> on each end, 12.0(21)S on each router.
>
> I can't run ospf between the two because of this:
>
> Sep 11 10:35:46: OSPF: Rcv DBD from x.y.z.w on Tunnel0 seq 0x8C9 opt 0x42 flag 0x7 len 32 mtu 4446 state EXSTART
> Sep 11 10:35:46: OSPF: Nbr x.y.z.w has larger interface MTU
>
> Any suggestions?
>
> If I change the MTU on my DS3 to 1500 then what happens
> to the 1514 MTU on the tunnel?
>
> Thanks,
> -mark

I believe the tunnel interface inherits from its parent.
However, you can override by applying "ip mtu 1500" to the tunnel
interface itself. I've had this problem and fixed it that way.

Tony