OSPF over GRE on EOS

[DanPartelly]

Convoluted madness:

Seems to need:

interface tunnel X
....
tunnel path-mtu-discovery -> else you cant change ttl
tunnel ttl 255 -> default is 1, the other IP header is generated with TTL1

router ospf 1
tunnel routes -> else you'll get the OSPF neighbours, but no OSPF routes will be loaded from them

default routes are not propagated without yet another setting in ospf process.

I'm on ceos:4.34.1F.

[ipspace]

Well, EOS is a switch operating systems, and switches (for whatever meaning of that overloaded term) usually don't need GRE tunnels.

I would suggest we just add a note to the platform support table saying that EOS requires too many nerd knobs for GRE to work, so we decided not to do it.

[DanPartelly]

Yeah, I agree. It's not there as functionality anyway. I tried IS-IS. As expected, it formed an adjacency immediately and exchanged routes, but for every ICMP echo, I got 4 answers (3 DUPS )

[ipspace]

You could start wireshare and figure out what's going on, but I would instead recommend to run away as fast as you can 🤦‍♂️

Also, this is not something I want to see implemented in netlab.

[DanPartelly]

I was gone in 60 seconds. And yes, no one wants this in Netlab.