To announce connected prefixes, or not to announce connected prefixes,
that is the question...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds the PtMP interface type, which is effectively identical to PtP
except that all the database flooding & updates are unicast.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some lower layers still don't handle multicast correctly (or
efficiently.) Add option to send unicast hellos on explicitly
configured neighbors for PtP/PtMP.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the configured neighbor list, unicast hellos can be sent. Allow
disabling multicast hellos for that scenario.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds a knob to refuse forming adjacencies with neighbors not listed
in the config. Only works on PtP/PtMP of course, otherwise the DR/BDR
machinery gets broken.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add a list of configured neighbors for each interface. Only stores cost
(and "existence") for now.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
For PtMP the cost may need to be recalculated when the LL addr changes
(since neighbors are configured by LL addr and a different entry with a
different cost may match.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Both for virtual links and correct PtMP operation, advertising local
addresses as Intra-Prefix with LA set is a prerequisite. Add the
appropriate entries.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When netlink_link_change() errors out for a new link for
interface without MTU set, the allocated ctx is not freed..
Adding code for correctness
Ticket# 3628313
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
At each EBGP boundary, BGP path attributes are modified as per [RFC4271], which includes stripping any IBGP-only attributes.
Some networks span more than one autonomous system and require more flexibility in the propagation of path attributes. It is worth noting that these multi-AS networks have a common or single administrative entity. These networks are said to belong to One Administrative Domain (OAD). It is desirable to carry IBGP-only attributes across EBGP peerings when the peers belong to an OAD.
This document defines a new EBGP peering type known as EBGP-OAD, which is used between two EBGP peers that belong to an OAD. This document also defines rules for route announcement and processing for EBGP-OAD peers.
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The code doesn't work at all. It tries to use libyang operation
metadata in a regular (not diff) data tree, and regular data trees
don't provide this data. Also, for destroy operations, it searches
for nodes in the running config, which may not have the deleted nodes
if we're not using implicit commits.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Include a zclient value in the hash and tree key computations
for iprules in zebra: clients may collide without this.
Signed-off-by: Mark Stapp <mjs@labn.net>
The iprule/pbr rule object has a vrf id, and zebra uses
that internally, but the vrf id isn't returned to clients
who install rules and are waiting for results. Include the
vrf_id sent by the client in the zapi result notification
message; update the existing clients so they decode the id.
Signed-off-by: Mark Stapp <mjs@labn.net>
Don't hard-code a sharpd nhg id: those values aren't stable
if the daemons/protos/route-types change. Use json show output
to find the id in the 'resilient' nhg test case in
the all_protocol_startup suite.
Signed-off-by: Mark Stapp <mjs@labn.net>
XSTRDUP and then calling strsep mangles the
pointer returned by XSTRDUP. Keep a copy
of the orig and when we are done, free that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA
message
The RFC-3618, section 12.2.1, describes the fields included in the MSDP
SA message. The "RP address" field is "the address of the RP in the
domain the source has become active in".
In the most common case, we will establish an MSDP connection from RP to
RP. However, there are cases where we want to establish a MSDP
connection from an interface/address that is not the RP. Section 3 of
RFC-3618 describes that scenario as "intermediate MSDP peer". Moreover,
the RP could be another router in the PIM domain - not the one
establishing the MSDP connection.
The current implementation could be problematic even with a single
router per PIM domain. Consider the following scenario:
* There are two PIM domains, each one with a single router.
* The two routers are connected via two independent networks. Let's say
that is to provide redundancy.
* The routers are configured to establish two MSDP connections, one on
each network (redundancy again).
* A multicast source becomes active on the router 1. It will be
communicated to router 2 via two independent MSDP SA messages, one per
MSDP connection.
* Without these changes, each MSDP SA message will indicate a different
RP.
* Both RP addresses will pass the RPF check, and both MSDP sources will
be accepted.
* If the router has clients interested in that multicast group, it will
send PIM Join messages to both RPs and start receiving the multicast
traffic from both.
With the changes included in this commit, the multicast source available
in router 1 would still be communicated to router 2 twice. But both MSDP
SA messages would indicate the same RP, and one of them would be
discarded due to failure in the RPF-check failure. Also, the changes
allow us to define the RP that will be included in the MSDP SA message,
and it could be one of the interfaces used to establish the MSDP
connection, some other interface on the router, a loopback interface, or
another router in the PIM domain.
These changes should not create compatibility issues. As I mentioned, we
usually establish MSDP connections from RP to RP. In this case, the
result will be the same. We would still indicate the address used to
establish the MSDP connection if the RP is not set - I wonder if that
should even be a valid configuration.
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
Changing Addpath type, and or disabling RX (receiving) flag, we can do this
without tearing down the session, and using dynamic capabilities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When we have RX/TX flags, but received only TX, we should clear RX flag, to avoid
receiving additional paths.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add a topotest to check for proper functioning of the
bgp large community list match operation under a route-map.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no match mechanism to match one community from the
incoming community-list. Add the 'any' keyword to the 'match
route-map' command of communit-list and large-community-list.
> match community-list AAA any
> match large-community-list AAA any
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Adjust protocol command values for zebra based on latest code.
Also, expand the field width to fit the length.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
When interface addresses change, we examine nhgs associated
with the interface in case they need to be reinstalled. As
part of that, we may need to reinstall ecmp nhgs that use the
interface being examined - but not always.
Signed-off-by: Mark Stapp <mjs@labn.net>
