Add Tunnel support for EOS

[snuffy22]

Add GRE support for EOS.

Passes tests as expected.

Do we want to update the 02-gre-vrf.yml test ?

(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/tunnel$ netlab up -p clab -d eos 01-gre.yml

(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/tunnel$ netlab validate
[g4_adj_v4]  Check OSPF adjacencies (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: OSPFv2 neighbor 10.0.0.1 is in state Full/-
[PASS]       Test succeeded in 0.1 seconds

[g4_adj_v6]  Check OSPFv3 adjacencies (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: OSPFv3 neighbor 10.0.0.1 is in state Full
[PASS]       Test succeeded in 0.1 seconds

[g4_pfx_v4]  Check DUT IPv4 loopback prefix propagation (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: The prefix 10.0.0.1/32 is in the OSPF topology
[PASS]       Test succeeded in 0.1 seconds

[g4_pfx_v6]  Check DUT IPv6 loopback prefix propagation (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: The prefix 2001:db8::1/128 is in the OSPFv3 topology
[PASS]       Test succeeded in 0.1 seconds

[g4_ping_v4] Check end-to-end IPv4 connectivity (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: Ping to 10.0.0.1 from 10.0.0.2/32 succeeded
[PASS]       Test succeeded in 0.1 seconds

[g4_ping_v6] Check end-to-end IPv6 connectivity (GRE IPv4) [ node(s): r2 ]
[PASS]       r2: Ping to ipv6 2001:db8::1 from 2001:db8::2/128 succeeded
[PASS]       Test succeeded in 0.1 seconds

[f_warning]  Starting test
[WARNING]    eos does not support GRE tunnels over IPv6

[INFO]       One test out of 7 tests generated a warning
(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/tunnel$

[DanPartelly]

See #3571, Ivan doesnt really wanted it in Netlab.

[snuffy22]

@DanPartelly mm what i get for not looking at all the discussions before tinkering.. ;)

[ipspace]

See #3571, Ivan doesnt really wanted it in Netlab.

Where did you get that impression from? I just told you to run away ;)

@snuffy22 -- to solve this properly, you'd have to (A) figure out whether the "tunnel routes" applies only to OSPF or to all IGPs and then (B) add a device quirk that would set the corresponding flag in routing protocol data, followed by (C) modification of all routing protocol configuration templates.

What you did was unfortunately "developing against the test", and even that would fail if we tested the tunnels in VRFs (not using VRFs for transport)

[snuffy22]

@ipspace, guilty about for developing against the test.
I will re-visit it after I fix the other few PRs i've made problems for =/

[DanPartelly]

Where did you get that impression from? I just told you to run away ;)

Probably context was off ? I got the impression literally from, and I quote:

"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. "

[snuffy22]

Did a little extra digging..
IPv4 GRE tunnel:

• RIPv2 seemed ok without any knobs
• OSPFv3 seemed ok without any knobs
• BGP seemed ok without any knobs
• ISIS also was ok without any knobs

[DanPartelly]

ISIS for my image returned 4 duplicates for any ICMP echo. Please test it manually.

[snuffy22]

I will look into it in the next day or so and get back if i can produce same issue..

[DanPartelly]

I will look into it in the next day or so and get back if i can produce same issue..

Thank you, and thank you for your prolific contributions to Netlab.

[snuffy22]

Yep.. can confirm DUP.

I tried expanding my lab to have a host on either side,
Just so I could remove maybe it didn't like talking to the router..

h1 -> r2(GRE) -> dut -> (GRE)r3 -> h2

When pinging from h1 -> h2 I got 3 DUP responses.

Now if I did a little python http server on h1 and had h2 download a test index.html..
I saw no duplicates in the 'capture' output.

Seems like it does not like ICMP related packets, feels like they need 'friends'.
But tunnel itself seems to handle traffic ok 🤷‍♂️

[ipspace]

OK, @snuffy22 @DanPartelly, what should we do? Finalize this, declare the caveats, and merge, or forget it?

[DanPartelly]

Merge it, with documented caveats.

[Copilot]

Pull request overview

This PR adds Arista EOS support to the existing tunnel.gre extra plugin, enabling GRE-over-IPv4 tunnels (including transport VRF) and documenting EOS-specific tunnel/OSPF caveats.

Changes:

• Added an EOS GRE tunnel configuration template for the tunnel.gre plugin.
• Declared EOS GRE tunnel feature support (IPv4 + VRF) in the EOS device feature map.
• Enabled the EOS OSPFv2 tunnel routes setting and documented EOS GRE tunnel caveats.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
netsim/extra/tunnel/gre/eos.j2	Adds EOS-specific GRE tunnel interface configuration (mode, underlay VRF, src/dst, PMTUD, TTL).
netsim/devices/eos.yml	Advertises EOS tunnel.gre feature support for ipv4 and vrf.
netsim/ansible/templates/ospf/eos.ospfv2.j2	Enables tunnel routes in EOS OSPFv2 configuration to ensure tunnel-reachable routes are considered.
docs/plugins/tunnel.gre.md	Updates the GRE plugin supported-platform matrix to include Arista EOS capabilities.
docs/caveats.md	Documents EOS-specific GRE tunnel caveats (OSPFv2 tunnel routes, IS-IS behavior, and cEOS forwarding quirks).