SVI in EBGP-sessions.

[PolinaOrehova]

Hi. I'm trying to write a topology in .yml for evpn-vxlan, I'd really like to do without additional configs.
There was a problem: bgp-session for SVI is generated automatically. For my topology they need to be disabled. How can this be done?
I give an topology.txt, example of expected config and result_config.

If I do something wrong in my configuration, please point it out.

Thanks in advance!

[ipspace]

That's interesting. Somehow netlab decides every router has BGP neighbors in a VRF (technically true, accessible over the VLAN) and sets up the sessions. I have to figure out why that happens (as I haven't seen it before), and then either to fix it or to give you a workaround. It will definitely take me a few days.

[ipspace]

Setting bgp: false in the side1 VRF solves the problem in my test.

vrfs:
  side1:
    evpn.transit_vni: 20001
    bgp: false

The BGP sessions were established because the routers in the same VLAN had different AS numbers. I have to build a smaller topology to test the details, but it looks like you get the unwanted sessions only if the VLANs are in a VRF (which you want to have to test EVPN-driven IRB).

Admittedly, we never tested this particular combination. Thanks a million for uncovering this problem and reporting it.

[PolinaOrehova]

Thanks for the quick answers :)

I tried to disable BGP for VRF by removing VLAN from it (otherwise an error occurs when generating configs), but in this case SVI sessions "moved" to the main BGP configuration. I can send such a configuration option and the resulting config, if it is informative.

[ipspace]

Good day. I used netlab from the dev branch, thanks for the prompt update.

👍 Thanks for the feedback!

The problem with bgp sessions in vrf remains if bgp is enabled for vrf.

Correct. That's ipspace/netlab#2477 and it hasn't been fixed yet, but at least we have a workaround (next step: documenting it)

The problem goes away if you disable bgp for vrf (the config is created correctly, the error associated with the lack of neighbors does not occur when creating a lab). Is this the correct behavior of netlab after the fix?

Yes. Hope you'll be able to build your target topology now (and eventually the other issue will be fixed as well). If you encounter further problems, please open an issue in https://github.com/ipspace/netlab/issues/ as it will most probably be another bug. I'm sure you're far past the initial hurdles by now.

[PolinaOrehova]

Oh, sorry, I seem to have too many questions in the discussion, that started for the sake of a small clarification. And I'm not quite sure that this is a bug and not standard behavior.

Based on my topology (I provided it above) and with netlab from the dev branch, when trying to generate a graph, I get a somewhat strange result. Is this correct behavior?

[ipspace]

Oh, sorry, I seem to have too many questions in the discussion, that started for the sake of a small clarification.

Absolutely not a problem, it's just that most of the discussions happen in the other repository, so I'd expect people to search there first.

Based on my topology (I provided it above) and with netlab from the dev branch, when trying to generate a graph, I get a somewhat strange result. Is this correct behavior?

Yeah, it is. Netlab creates only the graph description, and then the graphing tool (GraphViz or D2) tries its best to place nodes and links without knowing what a network is. Your result is surprisingly good considering what I've seen in the past 🤷‍♂️

If you ever happen to stumble upon a good graphing tool that takes text files as an input and does auto-placement, please let me know.

[PolinaOrehova]

The questions arose not because of the beauty of the graph, it is beautiful by the fact of its existence, thanks for this tool :)
, but with the connection between the host and leaf via a subnet, and not a direct link, although it exists in the topology. It looks a bit like an "echo" of problems with bgp sessions, although I may be mistaken.

[ipspace]

but with the connection between the host and leaf via a subnet, and not a direct link, although it exists in the topology. It looks a bit like an "echo" of problems with bgp sessions, although I may be mistaken.

Yeah, the VLAN topologies can result in somewhat surprising graphs as we always model VLANs as LAN interfaces (even when there are only two nodes attached to the VLAN). Have to add another graph type that strictly reflects the topology links.

[ipspace]

FWIW, you can straighten the lines in the graph if you add "splines=false" graph attribute to graph.dot (immediately after graph { line). I opened an enhancement suggestion to add "graph" attributes to lab topology:

ipspace/netlab#2509