Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
There is no match mechanism to match one community from the
incoming community-list. Add the 'any' keyword to the 'match
route-map' command of communit-list and large-community-list.
> match community-list AAA any
> match large-community-list AAA any
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
We should not allow exceeding the stream's length, and also software version
can't be larger than 64 bytes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fix printing link state ospf opaque data. pnt address was not moving
in the loop.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix an issue where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568380 (#1 of 1): Untrusted value as argument (TAINTED_SCALAR)
> 9. tainted_data: Passing tainted expression length to bgp_linkstate_nlri_value_display, which uses it as an offset
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix issues where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568378 (#1-6 of 6): Untrusted value as argument (TAINTED_SCALAR)
> 16. tainted_data: Passing tainted expression length to bgp_linkstate_tlv_attribute_value_display, which uses it as an offset. [show details]
Fixes: 7e0d9ff8ba ("bgpd: display link-state prefixes detail")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix comparaison of link state attributes pointers in
link_state_hash_cmp().
> CID 1568379 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return false;.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix illegal memory access bgp_ls_tlv_check_size() if type is 1253.
> CID 1568377 (#4 of 4): Out-of-bounds read (OVERRUN)
> 5. overrun-local: Overrunning array bgp_linkstate_tlv_infos of 1253 16-byte elements at element index 1253 (byte offset 20063) using index type (which evaluates to 1253).
Fixes: 7e0d9ff8ba ("bgpd: display link-state prefixes detail")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix the following coverity issue. attr cannot be NULL.
> CID 1568376 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking attr suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When we accept a connection, we try to set TTL for the socket, but the socket
is not yet created/assigned and we are trying to set it on the wrong socket fd.
```
[Event] connection from 127.0.0.1 fd 25, active peer status 3 fd -1
can't set sockopt IP_TTL 255 to socket -1
bgp_set_socket_ttl: Can't set TxTTL on peer (rtrid 0.0.0.0) socket, err = 9
Unable to set min/max TTL on peer 127.0.0.1, Continuing
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Avoid having something like this in outputs:
Before:
```
munet> r1 shi vtysh -c 'show bgp dampening damp'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network From Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 (null) 65002 ?
Displayed 5 routes and 5 total paths
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network From Flaps Duration Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
Displayed 5 routes and 5 total paths
```
After:
```
munet> r1 shi vtysh -c 'show bgp dampening damp '
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network From Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 00:00:00 65002 ?
Displayed 5 routes and 5 total paths
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network From Flaps Duration Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
Displayed 5 routes and 5 total paths
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When BGP is sending updates to peers on a neighbor up event
it was noticed that the bgp updates being sent were in reverse
order being sent to the first peer.
Imagine r1 -- r2 -- r3. r1 and r2 are ebgp peers and
r2 and r3 are ebgp peers. r1's interface to r2 is currently
shutdown. Prior to this fix the send order would look like this:
r1 -> r2 send of routes to r2 and then they would be installed in order
received:
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r2 would then send these routes to r3 and then they would be installed
in order received:
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
Not that big of a deal right? Well imagine a situation where r1 is
originating several ten's of thousands of routes. It sends routes to r2
r2 is processing routes but in reverse order and at the same time it
is sending routes to r3, in the correct order of the bgp table.
r3 will have the early 10.0.0.1/32 routes installed and start forwarding
while r2 will not have those routes installed yet( since they were at the
end and zebra is slightly slower for processing routes than bgp is ).
Ensure that the order sent is a true FIFO. What is happening is that
there is an update fifo which stores all routes. And off that FIFO
is a bgp advertise attribute list which stores the list of prefixes
which share the same attribute that allow for more efficient packing
this list was being stored in reverse order causing the problem for
the initial send. When adding items to this list put them at the
end so we keep the fifo order that is traversed when we walk through
the bgp table.
After the fix:
r2 installation order:
10.0.0.0 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r3 installation order:
10.0.0.0 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Append zebra and lib to use muliple SRv6 segs SIDs, and keep one
seg SID for bgpd and sharpd.
Note: bgpd and sharpd compilation relies on the lib and zebra files,
i.e if we separate this: lib or zebra or bgpd or sharpd in different
commits - this will not compile.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
currently snmpwalk give results such :
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6z.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6z.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
the expected result is the following
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv4.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 =
INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv4.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex
-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
in draft-ietf-idr-bgp4-mibv2-11
INDEX for Bgp4V2PeerEntry is define as follows
INDEX {
bgp4V2PeerInstance,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr
}
the peer instance is defined as follows
OBJECT bgp4V2PeerInstance
SYNTAX Unsigned32 (1..4294967295)
more this interpretation is conformant with the snmpwalk implementation
for instance we obtain the following result
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemotePort.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Gauge32: 179
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemoteAs.1.ipv4.10.125.0.2 = Gauge32: 65200
since currently we are not supporting multi instance for bgp peer in
SNMP the bgp4V2PeerInstance value is set to 1 coforming to:
"Implementations that do not support multiple routing instances should return 1 for this object."
test is updated accordingly to fix.
currently index for bgp4V2NlriEntry is not coformant to MIB definition
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
currently an snmpwalk gives:
BGP4V2-MIB::bgp4V2PeerFsmEstablishedTime.1.ipv6z.10.125.0.2 = Gauge32: 103 seconds
BGP4V2-MIB::bgp4V2PeerFsmEstablishedTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Gauge32: 103 seconds
but ipv6z and dns are not the valid address type this must be ipv4 and
ipv6.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
snmpwalk exhibit the followinfg errors:
BGP4V2-MIB::bgp4V2PeerLastErrorReceivedTime.1.ipv6z.10.125.0.2 = Wrong Type (should be Timeticks): Gauge32: 0
BGP4V2-MIB::bgp4V2PeerLastErrorReceivedTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Wrong Type (should be Timeticks): Hex-STRING: 00 00 00 00 00 00 00 00
BGP4V2-MIB::bgp4V2PeerLastErrorSentTime.1.ipv6z.10.125.0.2 = Wrong Type (should be Timeticks): Gauge32: 178
BGP4V2-MIB::bgp4V2PeerLastErrorSentTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Wrong Type (should be Timeticks): Hex-STRING: B2 00 00 00 00 00 00 00
Error: OID not increasing: BGP4V2-MIB::bgp4V2NlriIndex.1.4.10.200."".0.24.10.125.0.2
>= BGP4V2-MIB::bgp4V2NlriIndex.1.4.10.200."".0.24."".0.0.0
draft-ietf-idr-bgp4-mibv2-11 states the following
bgp4V2PeerLastErrorReceivedTime OBJECT-TYPE
SYNTAX TimeStamp
bgp4V2PeerLastErrorSentTime OBJECT-TYPE
SYNTAX TimeStamp
we set the correct values
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
