Netlab extensibility and core features

[DanPartelly]

Ive followed the last exchange in #1494 with great interest. During the last days Ive got a glimpse of netlab's extensibility after looking at DMVPN examples and doing some of Ivan's BGP labs and looking how they where put together.

Also, Ive got a better understanding of what it shouldn't be a core netlab feature. No vendor specific protocols, no vendor specific features, no rarely used nerd-knobs, nu support for industry "patients" (loved this term from one of Ivan's videos and please make sure that Im not referring to anyone here with this term). Maybe not an exhaustive list.

So we have this. What I would like to know is Ivan's view of what class of features are definitively candidates to be implemented as a module in core.

[ipspace]

What I would like to know is Ivan's view of what class of features are definitively candidates to be implemented as a module in core.

We're still missing static routing, and there's nothing on traffic engineering. It might be nice to have a generic TE module that would work with RSVP-TE, SR-MLPS or SRv6. Also, now that we have LAG, it would be nice to have MLAG.

However, if you want to start with a plugin, I wouldn't say no to a DMVPN plugin ;))

[DanPartelly]

How did you imagined the DMVPN plugin ? Just build the routing technique (maybe with configurable support for all 3 phases) over GREs , or with full support for IPSEC structures (maybe in a separate plugin) ?

Should it support redundant designs ?

However, if you want to start with a plugin, I wouldn't say no to a DMVPN plugin ;))

[ipspace]

• Routing is mostly done apart from next-hop-self hacks that we could implement in the plugin or extend the routing modules. I would prefer having it done in the routing modules for consistency.
• Tunnel interfaces already exist.
• "All" we have to do is to set up NHRP and IPsec on those tunnel interfaces.

I have a DMVPN data model somewhere and could dig it up if you don't feel like starting from scratch.

[DanPartelly]

You would do me a great favor if you would not dig that out for me. Having a good data structure is 50% of the job. It will force me to understand some things I do not yet (I only encountered networking so far from the perspective of a programmer, not a network engineer. )

I have a DMVPN data model somewhere and could dig it up if you don't feel like starting from scratch.

[DanPartelly]

@ipspace Could we have IPSEC as separate plugin and make DMVPN depend on it? Building an ipsec configuration might be useful to people outside of a dmvpn as well.

[ipspace]

In theory, yes. In practice, which IPsec configuration are you talking about? Tunnel interfaces (VTI) or crypto maps or something else?

[DanPartelly]

isakmp / ipsec profiles, preshared keys, and protected VTI tunnel only. there might be a lot of legacy networks with cryptomaps, but is there any reason to start a new design with those ?

In theory, yes. In practice, which IPsec configuration are you talking about? Tunnel interfaces (VTI) or crypto maps or something else?

[ipspace]

isakmp / ipsec profiles, preshared keys, and protected VTI tunnel only. there might be a lot of legacy networks with cryptomaps, but is there any reason to start a new design with those ?

Go for it. It's an interesting starting point.