The multicast routing RTM_GETROUTE command does not use IIF/OIF
attributes, and the IPv6 version will refuse them with an error due to
being new netlink API and thus using strict validation.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These two structs happen to be the same size and have the family field
in the same spot, but the correct one to use here is rtmsg not ndmsg.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
zebra does not care about _notifications_ from the kernel regarding
multicast routing; we only use the MR netlink API to request stats from
the kernel by actively sending a RTM_GETROUTE.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Literally 4 minutes after hitting merge on Mark's previous fix for this
I remembered we have an `assume()` macro in compiler.h which seems like
the right tool for this.
(... and if I'm touching it, I might as well add a little text
explaining what's going on here.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Description:
- On removing just the route-map from the default-originate config,
update message is not sent to the peer,
and the properties set by route-map persists on peer's end,
until we do a clear bgp.
Fix:
- The flag which is set when default route is originated,
should be unset once "neighbor X.X.X.X default-orginate",
to remove route-map from "neighbor X.X.X.X default-orginate route-map Y",
so as to trigger the flow for sending an update.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Description:
- When there is change in route-map properties after
setting the route-map with default route, changes
will not reflect.
- When route-map associated with default-originate is
deleted, default route doesn't get withdrawn.
- When there is change in route-map default-originate flow
does not get triggered.
Fix:
- One of the flags needs to be unset for default-originate
flow to get triggered after change in route-map.
Have unset the flag, so that default originate flow can
be triggered.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Description:
Change is intended for fixing the inconsistencies present
while adjusting the SNT counters with default originate.
- SNT counter gets incremented on every change of policy associated
with default-originate, leading to inconsistencies.
- This fix has been added to ensure that the SNT counters gets
incremented and decremented only once during the creation and
deletion workflow of default-originate, and prevents
incrementing the counter during update flow.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
this commit containes 2 testcases that covers
1. Default originate behaviour on restarting the BGP daemon and FRR router
2. Default Originate behaviour on shut no-shutting the interface
Signed-off-by: ARShreenidhi <rshreenidhi@vmware.com>
Issue was reported by Donald, we were hitting
with key not found error and execution was
stopped, which is fixed by this PR.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
New output example:
2022-07-03 09:40:29.310 [DEBG] zebra: [JF0K0-DVHWH] rib_meta_queue_add: (0:254):4.5.6.8/32: queued rn 0x55937f586ee0 into sub-queue Kernel Routes
2022-07-03 09:40:29.321 [DEBG] zebra: [HH6N2-PDCJS] default(0:254):4.5.6.8/32 rn 0x55937f586ee0 dequeued from sub-queue Kernel Routes
Let's make it a bit more human readable.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It will be used to allow/deny using IPv4 reserved ranges (Class E) for Zebra
(configuring interface address) or BGP (allow next-hop to be from this range).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The bgp_conditional_advertisement topotest runs all the test cases in
the same function. It is not easy to debug it because the pytest
"--pause" argument does not make breaks between test cases.
Dispatch the test-cases into functions to benefit from the "--pause"
feature.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This is a slightly modified version of Hiroki Sato's version:
9ca79c941f
Handle the `ENOBUFS` on a OS basis since it could have been implemented
differently (OpenBSD for an example uses `RTM_DESYNC`).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
These values were named WITHDRAW and UPDATE. Yeah, you guessed it, those
are already #define's elsewhere (bgp_debug.h). Hilarity ensues.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Just some missing ones. Make zebra stop complaining, was getting
some messages from proto2zebra when doing testing, let's clean
that up from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Instead of having global allow_delete move it to
where it belongs in the zrouter data structure.
Additionally show this data in `show zebra`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When reading a multipath route and we detect an encoding
error from the kernel( yeah I don't think so either ),
let's tell the operator what happened to that route.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exists a possibility that an end operator has choosen
to compile FRR on an extremely old KERNEL that does not support
the SOL_NETLINK sockopt call. If so let's note it for them
instead of stuff silently not working.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of SOL_NETLINK for adding memberships of interest is
1 group per call. The netink_socket function implied that
the call could be a bitfield of values. This is not correct
at all. This will trip someone else up in the future when
a new value is needed. Let's get it right `now` before
it becomes a problem.
Let's also add a bit of extra code to give operator a better
understanding of what went wrong when a kernel does not
support the option.
Finally as a point of future reference should FRR just switch
over to a loop to add the required loops instead of having
this bastardized approach of some going in one way and some
going in another way?
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Moving the reusable code of pim_show_nexthop apis to common file
pim_cmd_common.c file and adding the json support for show ipv6 pim nexthop
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Problems Identified:
show ip pim nexthop cli didn't have json extension and
show ip pim vrf all upstream have improper json format
Description:
show ip pim nexthop command shows the nexthops that are being used.
Added json support for the command.
show ip pim vrf all upstream displays upstream information for all vrfs about a S,G mroute.
Formatted the json structure for this command.
Signed-off-by: nsaigomathi <nsaigomathi@vmware.com>
