Modify the bmp_process() function to export the route update information
to all BMP instances importing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Only the peer transition events of the local BGP instance where BMP
is configured, were handled.
Add the support for peers from imported BGP instances:
- Add an internal API bmp_send_bt() function to handle stream
emission per bmp target
- Modify the BMP peer transition code to export the peer status
notifications to all BMP instances importing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon route update, the list of available BGP instances that
import the BGP instance where this updates comes from, is checked.
For each eligible BGP instance, the route update is sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Separate the bmp_route_update() function in two, by passing
the bgpbmp structure to the internal function instead of
the bgp instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a configuration command to import BGP information from
another BGP instance. Specifically, it should be possible for
a user to have a BMP instance configured on the default VRF,
and be able to import the VRF information from the other BGP
VRF instances.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some BMP actions require to get the bgp instance of the
given peer. Instead of considering that the BGP BMP instance
is the BGP instance of the peer, let us use directly the
peer->bgp pointer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Drop eth3 shutdown from ospf6d.conf - it doesn't do anything there. And it
actually shouldn't do anything: eth3 on r7/r8 are used as loopback-like
interfaces to inject the address on eth2 into OSPFv3. So they need to be up
for eth2 to work as expected.
Based on original PR#16811 commit:
eth3 shutdown is not applied because it is ospf6d.conf.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Use router_json_cmp when checking for proper nexthops to get better
diagnostics in case of mismatches. Add step() messages to see which check
failed.
Based on original PR#16811 commit:
expect_num_nexthops() errors are not understandable.
Use router_json_cmp.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
This allows eliminating the superfluous yang_data object (which
is getting created used to call lyd_new_term then deleted). Instead
just call lyd_new_term() in the callback directly.
Signed-off-by: Christian Hopps <chopps@labn.net>
The users would know the failure of some case for the two commands, just
return the error ```CMD_WARNING_CONFIG_FAILED```.
Signed-off-by: anlan_cs <anlan_cs@126.com>
This was reused with BGP_NEXTHOP_ULTIMATE by error.
Fixes: 93fd9cbb50 ("bgpd: Validate imported routes next-hop that is in a default VRF")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
"ip/ipv6 protocol any route-map <route map>" cli is setting
wrong route type ( ZEBRA_ROUTE_MAX ), It should set route type
ZEBRA_ROUTE_ALL.
Ticket: #4101560
Signed-off-by: Sougata Barik <sougatab@nvidia.com>
Fixing compilation error in a switch statement case
Fixes :aa4786642c9a65c282d0fd5247a35b0f14fa1c3c
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
When reloading the following configuration:
```
vrf red
rpki
rpki cache tcp 172.65.0.2 8282 preference 1
exit
exit-vrf
```
frr-reload.py does not properly enter the `rpki` context
within a `vrf`. Because of this, it fails to apply RPKI
configurations.
Signed-off-by: Jonathan Voss <jvoss@onvox.net>
When deactivating babel no router babel and later re-enabling it router babel the previous configuration is still in place.
Steps to reproduce:
Enable babel
Configure babel
Disable babel with "no router babel"
Verify config
Expected correct behavior: No config present
Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>
