We should involve checking received (not only advertised) capability, because
otherwise we put both peers (one with LL capability, another without) into a
single update-group and send 16-bytes NH instead of 16-bytes and 32-bytes
separately.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In case interface address is learnt during configuration, make sure to
run DR election when configuring PIM/PIM passive on interface.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO. This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.
In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
PPT to 0 (RFC 4601 sec 4.5.2).
When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
(S,G) entry only after ~10 minutes when there is no active traffic.
Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.
Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.
Ticket: #13703
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Use a memory allocation specific type for filter names (to help detect memory
leaks) and fix a memory leak when releasing peer memory.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This leak is happening:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
0 0x7f6922eb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7f6922a38ebb in qcalloc lib/memory.c:106
2 0x7f6922a553d6 in nexthop_add_srv6_seg6 lib/nexthop.c:652
3 0x562825e56b38 in parse_nexthop_unicast zebra/rt_netlink.c:589
4 0x562825e58c4a in netlink_route_change_read_unicast_internal zebra/rt_netlink.c:1291
5 0x562825e58eef in netlink_route_change_read_unicast zebra/rt_netlink.c:1321
6 0x562825e64921 in netlink_route_change zebra/rt_netlink.c:1494
7 0x562825e43407 in netlink_information_fetch zebra/kernel_netlink.c:407
8 0x562825e439b5 in netlink_parse_info zebra/kernel_netlink.c:1148
9 0x562825e44060 in kernel_read zebra/kernel_netlink.c:510
10 0x7f6922aeca72 in event_call lib/event.c:1984
11 0x7f6922a19e01 in frr_run lib/libfrr.c:1246
12 0x562825e4b0b9 in main zebra/main.c:543
13 0x7f692250c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Just check to see if it has been allocated. The nexthop is a stack
variable so it's a bit odd.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Memory is being leaked when processing the eoiu marker.
BGP is creating a dummy dest to contain the data but
it was never freed. As well as the eoiu info was
not being freed either.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The L2 attribute extended community can not be decoded when using L2VPN
EVPN as a route reflector. Decode the extended community and dump the
detailed information about flags and MTU information.
> rt4# show bgp l2vpn evpn
> BGP table version is 1, local router ID is 4.4.4.4
> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
> EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
> EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
> EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
> EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
> EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
>
> Network Next Hop Metric LocPrf Weight Path
> Route Distinguisher: 1.1.1.1:100
> *>i[1]:[12]:[00:00:00:00:00:00:00:00:00:00]:[32]:[0.0.0.0]:[0]
> 1.1.1.1 100 0 i
> RT:65500:100 L2: P flag:N, B Flag N, C word N, MTU 0
> Route Distinguisher: 5.5.5.5:100
> *>i[1]:[10]:[00:00:00:00:00:00:00:00:00:00]:[32]:[0.0.0.0]:[0]
> 5.5.5.5 100 0 i
> RT:65500:100 L2: P flag:N, B Flag N, C word N, MTU 0
>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The command fast-reroute lfa tiebreaker [downstream | lowest-backup-metric | node-protecting] index (1-255) [level-1 | level-2] will overwrite configurations with the same index but different types. This is because the index is set as the key in frr-isisd.yang. However, the lfa_tiebreaker_cmp function uses a tuple (index, type) as the key. Therefore, the yang file should be modified to stay in sync with the business logic.
Test Scenario:
On RouterA, first configure fast-reroute lfa tiebreaker downstream index 100 level-1, then configure fast-reroute lfa tiebreaker lowest-backup-metric index 100 level-1, and check the configuration:
!
router isis 10
fast-reroute lfa tiebreaker lowest-backup-metric index 100 level-1
exit
!
Signed-off-by: baozhen-H3C <bao.zhen@h3c.com>
