Description:
Per neighbor GR enabled information is missing from json
output in "show ip ospf gr helper details json" command.
Example config:
frr(config-router)# graceful-restart helper enable 2.2.2.2
frr(config-router)#
frr(config-router)# do show ip ospf graceful-restart helper detail
OSPF Router with ID (10.112.156.220)
Graceful restart helper support disabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Enable Router list:
2.2.2.2,
frr(config-router)# do show ip ospf graceful-restart helper detail json
{
"routerId":"10.112.156.220",
"helperSupport":"Disabled",
"strictLsaCheck":"Enabled",
"restartSupoort":"Planned and Unplanned Restarts",
"supportedGracePeriod":1800,
}
frr(config-router)#
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Handle matching type2/5 evpn routes via lookup in the optimized
route-maps used by plists.
Convert the evpn_prefix to ipv4/v6 prefix to perform longest
matching on in the tree.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Implement the ability to match type-2 and type-5 routes
via a route-map and a prefix-list.
Add some library code to convert an evpn prefix into
a general ipv4/ipv6 prefix for type-2 and type-5 routes.
evpn prefix is really just another subtype of prefix so all
the info needed can be extracted right there.
Add a special handler to bgp_routemap for evpn type routes
when applying the outbound route-map. This calls the library
code to convert the evpn_prefix to a ipv4/ipv6 prefix and
run it through the plist code. In this we assume type-2 routes
are a /32.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add route-map as a possible word for the `no` form
of `advertise ipvX *** [route-map WORD] cmd.
Before this patch the cmd was only accepted if `no` form
was given without route-map WORD. So if you just copypaste
the original version of the cmd, it would fail.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Implement forcing L3 auto derivation via configs even when
manually RTs are set. This will allow both to coexist in
BGP RTs. Without using auto config command, it will remove
auto derived RTs when you manually configure your own. To allow
both, use the auto command ond import/export/both.
Implement '*' wildcard import L3 RTs so we can import a route into any AS.
This is necessary to avoid a user from having to configure an L3 RT for
every AS they care to import evpn route from.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Abstract the ecommunity into a container struct for L3
route targets so that we can add some additional info
via flags to go along with RT configs without modifying
the used elsewhere ecommunity struct. This functions as a
wrapper everywhere its used including the import/export lists.
The flags will be used in later commits to change behavior
when importing/exporting routes.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
IPv4 and IPv6 behaves a little bit differently with the socket
options.
IPPROTO_RAW socket option is only for IPv4.
Therefore the register packet was not properly getting encapculated
for PIMv6 and was working fine for PIMv4.
So have used IPPROTO_PIM for PIMv6.
Fixes: #11846
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Add functionality to allow EVPN L3 RTs to be configured via
a list rather than one at a time.
Also add boilerplate config for forcing auto derivation of RTs
via config.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
BGP SoO is a tag that is appended on BGP updates to allow a peer to mark
a particular peer as belonging to a particular site. In certain MPLS L3 VPN
configurations, the BGP AS-Path may not provide the granularity needed
prevent a loop in the control-plane. With this in mind, BGP SoO is designed
to fill this gap and prevent a routing loop that may occur.
If we configure for example, `neighbor soo 65000:1` at PEs, routes won't be
announced between CPEs if soo matches. This is especially needed when using
as-override or allowas-in.
Also, this is the automated way of the same behavior as configuring route-maps
for each peer like:
```
bgp extcommunity-list cpe permit soo 65000:1
!
route-map cpe permit 10
set extcommunity soo 65000:1
...
route-map cpe deny 10
match extcommunity cpe
route-map cpe permit 20
...
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fix issue #11839.
When the user defines a range in an area other than the backbone area, the
summary route will be announced to the backbone area as an inter-area LSA.
However, if the prefix defined in the range is the same prefix as a connected
route in that area, the LSA won't be announced to the backbone area.
This is because when ospf6d is originating the summary route for the
intra-area route, it finds the range configured by the user and tries to
suppress the route by deleting the existing summary route, which happens to be
the one created by the range.
Although the range definition is not necessary in this case, it should not
fail this use case. So let's just keep the summary route there if it is
created from the user defined range.
Signed-off-by: Xiaodong Xu <stid.smth@gmail.com>
FRR only needs lua library (package libluaX.Y-dev) to be compiled and
linked, but its `configure` script makes use of lua interpreter to
perform its checks. Therefore, `luaX.Y` package is a requisite
build-dependency for debian packaging.
This commit adds the debian package with the lua interpreter to the
build dependencies.
Signed-off-by: Eugene Crosser <crosser@average.org>
Whn using as-override, we should be able to deny outgoing updates from
being propogated when `neighbor soo` is configured.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In kernel_socket.c, the code is deleting and then adding
the route back in on a change operation. This just translates
too two re's, one for deletion and one for addition. The deletion
will just be ignored. Let's not do the extra deletion.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
