New correct behavior:
eva# conf
eva(config)# ip pim rp 192.168.1.224 224.0.0.0/24
No Path to RP address specified: 192.168.1.224
eva(config)# ip pim rp 224.1.2.3 224.0.0.0/24
% Bad RP address specified: 224.1.2.3
eva(config)#
Fixes: #12970
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When an update group decides to not send a prefix
announcement because it has not changed, still increment
the version number. Why? To allow for the situation
where you have say 2 peers in 1 peer group and shortly
after they come up a 3rd peer comes up. It will be
placed into a separate update group and could be
coalesced down, when it finishes updating all data
to it. Now imagine that a single prefix changes at
this point in time as well. Then first 2 peers may
decide to not send the data, since nothing has changed.
While the 3rd peer will and since the versions numbers
never match they will never coalesce. So when the decision
is made to skip, update the version number as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) Make it legible what type of message is being passed
back and forth instead of having to guess it from
the insufficient debugs
b) Make it explicit which bgp instance is sending this
data
c) Cleanup bgp_zebra_update to have a cleaner api
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The "show zebra mpls .. json" vty command may return empty information
in case the MPLS database is empty or a given label entry is not
available. When those errors occur, add the braces to return a
valid json format.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The GR debug logs are doing all sorts of wonderful stuff
but they were not actually displaying anything useful to the operator
about what vrf we are operating in.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This causes early return. peer->conf is NULL for IPv6 link-local peering,
and the session never establish.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Automated new scenarios to multicast pim6
SM test suite. Added 10 test cases to verify
multicast PIM6-SM functionality.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Co-Auther: Vijay Kumar Gupta <vijayg@vmware.com>
Enhanced or added new libraries to support
multicast pimv6 automation
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Co-Auther: Vijay Kumar Gupta <vijayg@vmware.com>
Note that `ASNUM` in table, it is missing right parenthesis for
`(1-4294967295)`. So, adjust this table.
And correct other words for doc.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
This is already handled in bgp_nlri_parse() by checking error code.
Even more, we should send error sub-code to be according the NLRI type.
If it's MP_UPDATE/MP_WITHDRAW, sub-code should be an Optional Attribute error.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fixes a couple crashes associated with attempting to read
beyond the end of the stream.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
==21860==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 2 object(s) allocated from:
0 0x7f8065294d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7f8064cfd216 in qcalloc lib/memory.c:105
2 0x5646b7024073 in ecommunity_dup bgpd/bgp_ecommunity.c:252
3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
8 0x7f8064cc6acd in hash_walk lib/hash.c:270
9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
14 0x7f8064d891fb in thread_call lib/thread.c:1991
15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
16 0x5646b6feca67 in main bgpd/bgp_main.c:505
17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
0 0x7f8065294b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
1 0x7f8064cfcf01 in qmalloc lib/memory.c:100
2 0x5646b7024151 in ecommunity_dup bgpd/bgp_ecommunity.c:256
3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
8 0x7f8064cc6acd in hash_walk lib/hash.c:270
9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
14 0x7f8064d891fb in thread_call lib/thread.c:1991
15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
16 0x5646b6feca67 in main bgpd/bgp_main.c:505
17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The check with `ip->daddr == ip->saddr` in `bfd_recv_ipv4_fp()` is
useless, instead of it the ECHO packets should simply exit with
TTL checking failure regardless of this condition check.
Just remove the check.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Fix obvious bug where the wrong area filter-lists were being updated
in response to a prefix-list update.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The GR code should check for topology changes only upon the receipt
of Router-LSAs and Network-LSAs. Other LSAs types don't affect the
topology as far as a restarting router is concerned.
This optimization reduces unnecessary computations when the
restarting router receives thousands of inter-area LSAs or external
LSAs while coming back up.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC 5340, Section 4.8.3 says:
"Prefixes having the NU-bit set in their PrefixOptions field should
be ignored by the inter-area route calculation".
Fix a bug where, in addition to the NU-bit, ospf6d was also ignoring
prefixes having the LA-bit set when computing inter-area routes. In
practice, this fixes interoperability issues with vendors that set
the LA-bit in loopback prefixes (among other cases).
While here, fix a copy-and-paste error where a log message wasn't
showing accurate information about what happened.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Do not assume that all redistributed routes have a nexthop address,
otherwise blackhole nexthops can be misinterpreted as IPv6 addresses,
leading to inconsistencies.
Also, change the signature of a few functions to allow const nexthop
addresses, such that in6addr_any can be used without type casts.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Upon exiting the GR mode, force reorigination of intra-area-prefix-LSAs
on all attached areas. This is to ensure all configured areas will have
an associated intra-area-prefix-LSA at the end of the GR procedures,
even if the area doesn't have any full adjacency.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Originate AS-External LSAs with forwarding addresses whenever the
corresponding redistributed routes have a global nexthop address.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
