Since these systems are too old to correctly support the protocol
disabling the PIM6d.
Also by default disable on all. Use --enable-pim6d flag to
enable it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
By default, disable pim6d compilation. If someone
wants to enable the compilation, should use ./configure option
with --enable-pim6d.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Just adding two more attributes to decode and show nicely in netlink
msgdump debug output.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The IPv6 version needs rtm_src_len and rtm_dst_len filled in due to
strict validation. IPv4 also has this requirement, but zebra is running
in non-strict mode there so the kernel accepts it...
Also the table ID hack is IPv4 only.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
resolver_resolve should check hostname is null or not.
if ares_gethostbyname() get null hostname string, the hostname string will access a null pointer and crash.
Signed-off-by: kevinshen <kevinshen@inspur.com>
When there is change in route-map policy associated with default-originate, changes does not reflect.
When route-map associated with default-originate is deleted, default route doesn't get withdrawn
Update message is not being sent when only route-map is removed from the default-originate config.
SNT counter gets incremented on change of every policy associated with default-originate
Route-map with multiple match clauses causes inconsistencies with default-originate.
Default-originate behaviour on BGP-attributes
Signed-off-by: ARShreenidhi <rshreenidhi@vmware.com>
Description:
- When there are multiple policies configured with
route-map then the first matching policy is not
getting applied on default route originated with
default-originate.
- In BGP we first run through the BGP RIB and then
pass it to the route-map to find if its permit or
deny. Due to this behaviour the first route in
BGP RIB that passes the route-map will be applied.
Fix:
- Passing extra parameter to routemap_apply so that
we can get the preference of the matching policy,
keep comparing it with the old preference and finally
consider the policy with less preference.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Fixed ANVL Conformance PIM-SM 16.3 test case.
When (S,G,rpt) prune is received, we were installing
the mroute immediately with none as OIF.
This leads to dropping the (S,G) traffic during prune
pending time as well.
Also we should not install the mroute if there is no
change in the rpf update.
These 2 things lead to the failure of the test case.
Fixed it by blocking the installation in this scenario.
When prune pending timer pops, it will take care of
installing the mroute with none as OIF.
Fixes: #11535
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Use the destination for the operator `sizeof()` instead of the source
which could (and is) be bigger than destination.
We are not truncating any data here it just happens that the zebra
interface data structure hardware address can be bigger due to different
types of interface.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
For pim callbacks, we pass pim_addr as value, not pointer.
So making it consistent for pim_nht callbacks.
Signed-off-by: sarita patra <saritap@vmware.com>
In this PR, we are handling the pim_vxlan_orig_mr_up_add()
after rpf_addr modified from prefix to pim_addr.
Signed-off-by: sarita patra <saritap@vmware.com>
Currently rpf_addr is of type struct prefix, but it's always
a /32 host prefix. So changing it to pim_addr in order to support both
IPV4 and IPV6.
Signed-off-by: sarita patra <saritap@vmware.com>
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>
