When running the bgp_bmp_2 vrf test, peer vrf up/down events from the pre
and post policy are received with a wrong peer distinguisher value.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "0:0",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
RFC7854 mentions in 4.2 that if the peer is a "RD Instance Peer", it is
set to the route distinguisher of the particular instance the peer
belongs to.
Fix this by modifying the BMP client, update the peer distinguisher
value by filling the peer distinguisher in the bmp_peerstate function.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "444:1",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
Add a test to check that peer_distinguisher value is not 0:0 when an
RD instance is set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer up/down events from the pre
and post policy are received with a wrong peer type value
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-16 21:59:53.111962",
> "bmp_log_type": "peer up", "local_ip": "192.168.0.1", "local_port": 179,
> "remote_port": 50710, "seq": 4}
RFC7854 defines RD instance peer type, and later in 4.2 requests that
the peer distinguisher value be set to non zero value when the peer type
is not global. This is the case for peer vrf instances.
Fix this by modifying the BMP client, update the peer type
value by updating the peer type value when sending peer up/down messages.
Add a check in the bgp_bmp_2 test to ensure that peer type is correctly
set.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "0:0",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer route messages from the pre
and post policy are received with a wrong peer distinguisher value.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
RFC7854 mentions in 4.2 that if the peer is a "RD Instance Peer", it is
set to the route distinguisher of the particular instance the peer
belongs to.
Fix this by modifying the BMP client:
- update the peer distinguisher value by unlocking the filling of the peer distinguisher in the function.
This change impacts monitoring messages.
- add the peer distinguisher computation for mirror messages
- modify the bgp_bmp_2 vrf test, update the peer_distinguisher value
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "444:1", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer route messages from the pre
and post policy are received with a wrong peer type value
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
In addition to global instance peers, RFC7854 defines RD instance peers.
This value can be used for peers which are on a BGP VRF instance, for
example with an L3VPN setup.
When configuring a BGP VRF instance, the peer type should be seen as an
RD instance peer.
Fix this by modifying the BMP client:
- update the peer type for vrf mirror and monitoring messages
- modify bgp_bmp_2 vrf test to control the peer_type value
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
All BMP peer up/down messages send a 0:0 peer distinguisher.
This will not be ok when adding RD instance type.
Add code to get the peer distinguisher value.
- modify the API to pass the BGP instance instead of BMP.
- implement error cases with an unknown vrf identifier or a
peer type with local type value.
- handle the error return of the API; consequently, handle
the bmp_peerstate() error return in the calling functions.
There is no functional change, as the peer type value is
either loc-rib or global, both cases are already handled.
The next commit will handle the RD instance case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If a given L3VRF instance requests a peer distinguisher
for a peer up/down message, the AFI_UNSPEC afi parameter
will be used; no RD is chosen for this AFI.
Fix this by priorizing the AFI_IP value before the AFI_IP6
value. For instance, a router with both RD set for each
address-family, peer up/down messages will be sent with the
RD set to the one for AFI_IP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp test, peer_up message from the loc-rib
are received with a wrong peer type.
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false, "peer_ip": "0.0.0.0",
> "peer_distinguisher": "0:0", "peer_asn": 0, "peer_bgp_id": "0.0.0.0",
> "timestamp": "2024-10-16 21:59:53.111963", "bmp_log_type": "peer up", "local_ip": "0.0.0.0",
> "local_port": 0, "remote_port": 0, "seq": 1}
RFC9069 mentions in 5.1 that peer address must be set to 0.0.0.0,
and the peer_type value must be set to 3. Today, the value set
is 0 (global instance). This is wrong.
Fix this by modifying the BMP client, update the peer type value to
loc-rib on peer up messages.
Modify the current BMP test, by checking the peer up messages for the
0.0.0.0 IP address (which is the value used for loc-rib).
> {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "0:0", "peer_asn": 65501, "peer_bgp_id": "192.168.0.1",
> "timestamp": "2024-10-16 21:59:53.111963", "bmp_log_type": "peer up", "local_ip": "0.0.0.0",
> "local_port": 0, "remote_port": 0, "seq": 1}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At startup, there is no peer up message for loc-rib instance peer.
Instead, a global peer up message with address 0.0.0.0 is sent.
Such message is wrong, violates the RFC and should be dropped by
a strict collector. Actually, the peer type message sent is wrong,
and should be set to LOC-RIB peer type.
Fix this by changing the peer type of peer up message to either
loc-rib or global instance peer type.
Fixes: 035304c25a ("bgpd: bmp loc-rib peer up/down for vrfs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently the AIGP is always incremented when a route with the
attribute is advertised. That is incorrect when the nexthop is
unchanged, as is commonly the case in route reflection.
Adjust the AIGP for propagation only when the nexthop is set
to ourselves.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
added bmp bgp peer for vrfs
added peer up vrf in bmp peer up state
added vrf state in bmpbgp
added safe bmp_peer_sendall : bmp_peer_sendall_safe
changed bgp_open_send to call new bgp_open_make
bgp_open_make creates a bgp open packet, now used in bmp for peer up vrf
added hook and call to bgp instance state
vrf peer state is recomputed when interfaces (including vrf itf) go up / down
and when it gets created or removed
Link: e48ba38070
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
When trying to track down a MTYPE_TMP memory leak
it's harder to search for it when you happen to
have some usage of ttable_dump. Let's just give
it it's own memory type so that we can avoid
confusion in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix static-analyser warnings with BGP labels:
> $ scan-build make -j12
> bgpd/bgp_updgrp_packet.c:819:10: warning: Access to field 'extra' results in a dereference of a null pointer (loaded from variable 'path') [core.NullDereference]
> ? &path->extra->labels->label[0]
> ^~~~~~~~~
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Unconfiguring the send-experimental stats in BMP has no effect
on the current behavior.
Fixes this by swapping the configuration boolean.
Fixes: 7ba991cf96 ("bgpd: add 'bmp stat send-experimental' command")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no support for option 8, as per RFC7854.
Add the 64 bit counter in the peer structure.
Add the missing per peer statistic.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some wireshark versions can not decode the experimental
bmp stat code. This may also be the case for some collectors.
Add a vty command to be able to disable bmp to sending
those values.
> [no] bmp stat send-experimental
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no support for option 7, as per RFC7854.
Add the 64 bit counter in the peer structure.
Add the 64 bit bmp value write api.
Add the missing per peer statistic.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Support BMP monitoring for the BGP labeled VPN prefixes.
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
use CHECK_FLAG
fix comment spaces
change zlog_debug to zlog_warn
safeguard on updated_route
added doc/developer/bmp.rst to subdir.am
other qol changes
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
changed result type of bmp_get_peer_distinguisher to int
added result pointer parameter to bmp_get_peer_distinguisher
bmp_get_peer_distinguisher returns 0 means the result is valid else
error occured do not use result
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
moved loc-rib uptime field "bgp_rib_uptime" to struct bgp_path_info_extra for memory concerns
moved logic into bgp_route_update's callback bmp_route_update
written timestamp in per peer header
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
bgp_afi_node_lookup calls bgp_node_lookup which locks the node, unlocking it safely after function is finished
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
TODOs that are done/un-necessary now deleted
refactored bmp_route_update to use a modified bmp_process_one function call instead of duplicating similar code
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
cleaner implementation and use of the new get peer distinguisher function
can be now used for other cases of RFC7854 that are not supported atm
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
added time_t field to bgp_path_info
set value before bgp dp hook is called
value not set in the msg yet, testing and double checking is needed before
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set timestamp to 0 for loc rib monitoring messages as path selection time is not available atm
this is temporary and tv is meant to be set to the path selection/install time at some point
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
vrf_id_to_name is used for display values only and returns "Unknown" when the vrf is not found
doing a manual lookup and not providing any tlv when the vrf is not found should be better
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set field peer bgp id to the peer's remote id in every case except loc-rib (RFC9069 case) in which we put the bgp instance's router-id if available or 0-filled if not available
set field peer asn to local primary bgp asn in case of loc-rib instance (RFC9069) else it's set to the peer's asn
set field peer address to 0 in loc-rib instance (RFC9069 case) and to the peer's address in other cases
had to pass struct bgp reference to bmp_per_peer_hdr to access router-id and such, but it's always safely accessed when used
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
added afi/safi monitoring synchronisation for loc-rib
added peer_type_flag to bmp_eor signature, only set to BMP_PEER_TYPE_LOC_RIB and to 0 in other cases like it was before
updated tracelog to include peer_type_flag value
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set peer distinguisher to vrf id temporarily until i find out how to use the rd set for export on the vrf instance associated to this bgp instance
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set peer type flag to 3 for loc rib monitoring
leave to 0 in other cases like before, even though RFC7854 tells us to set it to 0 1 or 2 depending on the case global/rd/local instance
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
