Static routing

[ipspace]

Could also add a static-routing module with basic support for provisioning static routes:

• static routes to neighbor loopbacks (inferred)
• static routes associated with links (to peer if p2p, gateway for lan links)

Originally posted by @jbemmel in https://github.com/ipspace/netsim-tools/issues/124#issuecomment-1007023151

[ipspace]

@jbemmel What exactly would you like to see? Here are a few options:

• Static routes configured on hosts (in addition to #139)
• Static routes configured on individual network devices (specified in node data, next hop can be an IP or node ID/name or link)
• Global static routes (Q: why would they be useful?)

Also, if we use static routes toward node ID, are we assuming we're running an IGP (or whatever) to resolve next hop to that node's loopback interface?

[jbemmel]

The case that triggered my thinking is here: https://github.com/jbemmel/netsim-examples/blob/RFC4271-quirk/BGP/RFC4271-quirk/srlinux-static-peer-routes.j2

In your article about RFC4271 quirks, you refer to a multi-hop EBGP peering topology between loopbacks; for simplicity (I presume) it uses static routes to those loopbacks, instead of an IGP (which would complicate things somewhat).

I'm thinking this use case (of implicit static routes to the loopback of each node), with additional arbitrary static routes that can be declared on links (with resolution to the gateway) would be useful to support as a module

[ipspace]

The case that triggered my thinking is here: https://github.com/jbemmel/netsim-examples/blob/RFC4271-quirk/BGP/RFC4271-quirk/srlinux-static-peer-routes.j2

In your article about RFC4271 quirks, you refer to a multi-hop EBGP peering topology between loopbacks; for simplicity (I presume) it uses static routes to those loopbacks, instead of an IGP (which would complicate things somewhat).

Static routes make perfect sense, but what you'd like to see is a rare edge case that should be solved (if at all) with a plugin/Jinja2 template. Just to get EBGP session up and running between loopbacks would require another nerd knob or two in the BGP module or plugin modifying node.bgp.neighbors list. Guess which way I'm leaning ;)

Obviously once we support static routes, the plugin could make use of that infrastructure and add desired static routes as needed.

[petercrocker]

I was using static routes to shove traffic down a SR tunnel. I just whipped up a quick j2 template. I also did the same for adding a secondary loopback IP. Nice to have a "netsim" way of defining this config (static routes, secondary IPs), but I'd say not a priority since there's a current path for people to do any custom config (j2 templates).

[ipspace]

We've seen zero interest in this for months, and as @petercrocker said, you can always whip up a quick J2 template. Closing until a reasonable use case pops up.