After the ISIS daemon is launched, the configuration of an srv6
locator in zebra triggers a crash:
> #4 0x00007f1f0ea980f3 in core_handler (signo=11, siginfo=0x7ffdb750de70, context=0x7ffdb750dd40)
> at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:262
> #5 <signal handler called>
> #6 0x00005651a05783ef in isis_zebra_process_srv6_locator_add (cmd=117, zclient=0x5651a21d9bd0, length=25, vrf_id=0)
> at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_zebra.c:1258
> #7 0x00007f1f0ead5ac9 in zclient_read (thread=0x7ffdb750e750) at /build/make-pkg/output/_packages/cp-routing/src/lib/zclient.c:4246
> #8 0x00007f1f0eab19d4 in thread_call (thread=0x7ffdb750e750) at /build/make-pkg/output/_packages/cp-routing/src/lib/thread.c:1825
> #9 0x00007f1f0ea4862e in frr_run (master=0x5651a1f65a40) at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1155
> #10 0x00005651a051131a in main (argc=5, argv=0x7ffdb750e998, envp=0x7ffdb750e9c8)
> at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_main.c:282
> (gdb) f 6
> #6 0x00005651a05783ef in isis_zebra_process_srv6_locator_add (cmd=117, zclient=0x5651a21d9bd0, length=25, vrf_id=0)
> at /build/make-pkg/output/_packages/cp-routing/src/isisd/isis_zebra.c:1258
> (gdb) print isis
> $1 = (struct isis *) 0x0
> (gdb) print isis->area_list
> Cannot access memory at address 0x28
The isis pointer is NULL, because no instances have already been
configured on the ISIS instance.
Fix this by checking that there is any isis instance available when
zebra hooks related to srv6 are received.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Provide skeleton hooks for nexthop segments
Those hooks address seg6 segs stack entries defined in the YANG
model
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.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>
Provide a paragraph for srv6 multiple segs SIDs in documentation
to describe the multiple segs functionality.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Mostly to make coverity happy, no compiler/linker should produce broken
ELF files like this (and if it does we can't process it anyway...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
I think I originally had some other code at the tail end of that
function, but that's not the case anymore, and dropping out of the
function with a straight "return -1" is more useful than trucking on
with an invalid fd.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Mostly to make coverity happy, if dup() fails we're f*cked already.
(Still useful to have a better error message...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If VRF is not found by the given name, validate it and return an error.
Fixes: 76b2bc97e7 ("staticd: Accept full blackhole typed keywords for ip_route_cmd")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The previous change to assume() did address the coverity warning about
one direction of the shift in HASH_KEY, let's constrain the other in
HASH_SIZE as well.
To be fair, the hash table *will* break at 1G entries, but at that point
we have other problems RAM-wise. (Could bump the thing to 64-bit, but
then we need better item hash functions too on every single user.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Use oil_incoming_vif instead of oil_parent. I had
to go look this up as that I failed to remember that
the linux kernel calls this parent for some bizarre
reason.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
