Currently the ospf6d's commands with non-exist vrfs can't give the error
informations to users.
This commit adds a macro "OSPF6_CMD_CHECK_VRF" to give error information
if with non-exist vrfs. As usual, skip the checking process in the case
of json.
So one command can call this macro to do the checking process in its
end. At that time it need know json style or not, so add "json" parameter for
several related functions.
BTW, suppress the build warning of the macro `OSPF6_FIND_VRF_ARGS`:
"Macros starting with if should be enclosed by a do - while loop to avoid
possible if/else logic defects."
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Changed struct in_addr source_addr to struct PIM_ADDR source_addr
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr upstream_addr and struct in_addr upstream_register
to struct PIM_ADDR upstream_addr and struct PIM_ADDR upstream_register
which are to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr last_lookup to struct PIM_ADDR last_lookup
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr group_addr to struct PIM_ADDR group_addr
in struct igmp_group which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr address to struct pim_addr in struct
pim_iface_upstream_switch which is to be used in both IPv4
and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr group to struct pim_addr group
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr source_addr to pim_addr source_addr
in struct igmp_source which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr source_addr to pim_addr source_addr
in struct igmp_join which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Based on compiler option, pim_addr will be changed to in_addr
or in6_addr for pimd and pim6d respectively.
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This change is to accomodate IPv6 and IPv4 in the same code.
Based on pimd or pim6d, this will be compiled.
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr ifassert_winner to pim_addr
which will be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Comparison of the two pointer is confusing, they have no relevance
except the time both of them are empty.
Additionly modify one variable name and correct some comment words, they
are same in both ospfd and ospf6d.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The OSPF6_LSA_UNAPPROVED flag is set in the function above
ospf6_lsa_translated_nssa_new, so there is no need to set
the flag again
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
When running topotest ospf6_topo2 we can see a log message with wrong lsa id
2021/12/20 23:14:40.330 OSPF6: [V8P0C-HB5Z2] ASBR[default:Status:3]: Update
2021/12/20 23:14:40.330 OSPF6: [Z489N-JAJ6P] ASBR[default:Status:3]: Already ASBR
2021/12/20 23:14:40.330 OSPF6: [Z9D0B-12SBJ] Redistribute 2001:db8:2::/64 (connected)
2021/12/20 23:14:40.330 OSPF6: [N66XP-ANN4G] Advertise as AS-External Id:8.70.41.177 prefix 2001:db8:2::/64 metric 2 (**)
2021/12/20 23:14:40.330 OSPF6: [K4Y9R-C22T6] Advertise new AS-External Id:0.0.0.3 prefix 2001:db8:2::/64 metric 2
2021/12/20 23:14:40.330 OSPF6: [PKX0N-KNRQR] Originate AS-External-LSA for 2001:db8:2::/64
This PR removes the log (instead of fixing it) as same information is printed
in the following entry
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Since ospf6Enabled and attachedToArea are denoting the same thing.
It is decided to remove ospf6Enabled from json output to make
CLI and json output similar.
Fixes: #9286
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Added apis which will be decided on compile time
for pimd and pim6d daemon
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Added the High Level design for implementing MLD and PIMv6.
Added a PPT as well in case someone wants to translate it
to some other language.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
PIM_ADDR will be controlled at compile time for IPv4 and IPv6.
in_addr and in6_addr will be compiled for the respective daemons.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Description:
Change is intended for fixing the issue related to
clearing of stale leaked routes:
- Whenever BGP goes down,
after bringing down tcp connection and renegotiating capabilities,
once we reestablish connection,
we are not handling clear of VRF leaked route in the bgp_clear_stale_route.
- While bgp is clearing stale routes,
we need to handle withdraw of routes for VRF route-leaking.
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
The zlog_warn used to be bounded by a debug guard
but the debug guard was removed but the code was
never fixed up to remove the open and close paranthesis.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Extended BGP Administrative Shutdown Communication (rfc9003):
Basically, shutdown message size is increased to 255 from 128.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The test is doing this:
a) gather interface data about packets sent
b) shut interface
c) no shut interface
d) gather interface data about packets sent
e) compare a to d and fail if packets sent/received has not incremented
The problem is, of course, that under heavy system load insufficient time
might not have passed for packets to be sent between c and d. Add up to
35 seconds of looking for packet data being incremented else heavily
loaded systems may never show that data is being sent.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
