Closed jbemmel closed 2 years ago
/cc @bclasse @jbemmel was a link meant to point to the repo you opened issue in?
Hi @jbemmel , can you elaborate on that? From what I can see, host routes are propagated correctly in the fabric
Using Netlab
netlab up -d srlinux -p clab integration/evpn/vxlan-routing-ibgp-over-ebgp-unnumbered.yml
subinterface 1000 {
description "VLAN red1 (1000) ~ h1"
ipv4 {
address 172.16.0.1/24 {
primary
}
arp {
learn-unsolicited true
host-route {
populate dynamic {
}
}
evpn {
advertise dynamic {
}
}
}
}
}
to get
A:r1# /network-instance tenant2
--{ + running }--[ network-instance tenant2 ]--
A:r1# show route-table ipv4-unicast summary
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 unicast route table of network instance tenant2
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+-----------------------------------+-------+------------+----------------------+----------------------+----------+---------+---------------------+---------------------+
| Prefix | ID | Route Type | Route Owner | Active | Metric | Pref | Next-hop (Type) | Next-hop Interface |
+===================================+=======+============+======================+======================+==========+=========+=====================+=====================+
| 10.2.0.2/32 | 4 | host | net_inst_mgr | True | 0 | 0 | None (extract) | None |
| 10.2.0.4/32 | 0 | bgp-evpn | bgp_evpn_mgr | True | 0 | 170 | 10.0.0.2 | |
| | | | | | | | (indirect/vxlan) | |
| 172.16.2.0/24 | 9 | local | net_inst_mgr | True | 0 | 0 | 172.16.2.1 (direct) | irb0.1002 |
| 172.16.2.1/32 | 9 | host | net_inst_mgr | True | 0 | 0 | None (extract) | None |
| 172.16.2.5/32 | 9 | arp-nd | arp_nd_mgr | True | 0 | 1 | 172.16.2.5 (direct) | irb0.1002 |
| 172.16.2.255/32 | 9 | host | net_inst_mgr | True | 0 | 0 | None (broadcast) | |
| 172.16.3.0/24 | 0 | bgp-evpn | bgp_evpn_mgr | True | 0 | 170 | 10.0.0.2 | |
| | | | | | | | (indirect/vxlan) | |
| 172.16.3.6/32 | 0 | bgp-evpn | bgp_evpn_mgr | True | 0 | 170 | 10.0.0.2 | |
| | | | | | | | (indirect/vxlan) | |
+-----------------------------------+-------+------------+----------------------+----------------------+----------+---------+---------------------+---------------------+
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 routes total : 8
IPv4 prefixes with active routes : 8
IPv4 prefixes with active ECMP routes: 0
The fabric is only running a L2 service among the leafs with L3 endpoints on DCGWs, this config wouldn't apply to the current use case
Fair enough - so then the issue is that we are lacking a L3 topology showcase for EVPN
I'll close this one and create another one with the ask for L3 evpn instance
See https://github.com/srl-labs/nokia-evpn-lab/blob/main/configs/leaf1.cfg (for example)
To avoid traffic tromboning, the leaves should be configured to learn/send host routes based on IPs learned from ARP/ND