According to RFC 2236 Section 8.3
The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
As Maximum Response Delay refers to the maximum time interval within which an IGMP or MLD router
should respond to a query message. If both are equal, then both may expire at the same time.
So Query Interval must be greater than the query max response time.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
add support of color extended community, conforming to RFC 9012.
This extended community will be added to the existing one, RT,SOO
and Node Target. The configuration will be made through the
route-map service.
find above a configuration example:
router bgp 65001
bgp router-id 192.168.1.1
no bgp ebgp-requires-policy
no bgp network import-check
neighbor 192.168.1.2 remote-as external
neighbor 192.168.1.3 remote-as external
neighbor 192.168.1.4 remote-as external
address-family ipv4 unicast
network 10.10.10.10/24 route-map rmap
exit-address-family
!
route-map rmap permit 10
set extcommunity color 55555 200
exit
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
The main idea is to filter routes by matching source (originating) protocol
for outgoing direction. For instance, filter outgoing routes to an arbitrary
router that are static only. Or filter out only routes learned from RIP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Define the IS-IS flex-algo structure in yang, the CLI configuration
commands and the skeletons of frontend and backend functions that are
called by the CLI code.
Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Eric Kinzie <ekinzie@labn.net>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the ability to configure a Segment-Routing prefix SID for a given
algorithm. For example:
> segment-routing prefix 10.10.10.10/32 algorithm 128 index 100
Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
kttps://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.2 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.3 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r2 vtysh -c 'show ip bgp 10.10.10.10/32'
% Network not in table
unet> sh r3 vtysh -c 'show ip bgp 10.10.10.10/32'
BGP routing table entry for 10.10.10.10/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.1.1
65001
192.168.1.1 from 192.168.1.1 (192.168.1.1)
Origin IGP, metric 0, valid, external, best (First path received)
Extended Community: NT:192.168.1.3 NT:192.168.1.4
Last update: Tue Apr 11 23:19:33 2023
unet>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
- nice correspondence between new YANG grouping and shared library code.
- fixes bug with RIPNG use, certainly didn't work before.
- removes rip header from shared library code
- still has uses RIP_NODE/RIPNG_NODE as required by CLI foo.
Signed-off-by: Christian Hopps <chopps@labn.net>
New config functionality:
r1# conf
r1(config)# router isis 1
r1(config-router)# log-
log-adjacency-changes Log changes in adjacency state
log-pdu-drops Log any dropped PDUs
r1(config-router)# log-pdu-drops
r1(config-router)# end
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
It's not allowed to install routes with zero distance, let's disallow this
for route-maps as well.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The following command is not working:
> (routemap) set aggregator as ASNUM A.B.C.D
Since "aggregator-asn" has already supported asdot,
fixed it with new yang type. Extra ASN validation
(leading zeroes for instance) are done in the validate
hook of the yang leaf.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
New config and show functionality:
r1# conf
r1(config)# router isis 1
r1(config-router)#
advertise-high-metrics Advertise high metric value on all interfaces
area-password Configure the authentication password for an area
...
r1(config-router)# advertise-high-metrics
r1(config-router)# end
r1# show isis summary
...
Area 1:
Net: 49.0001.1720.1700.0002.00
TX counters per PDU type:
L2 IIH: 1
P2P IIH: 36
LSP RXMT: 0
RX counters per PDU type:
Advertise high metrics: Enabled
Level-2:
...
r1# conf
r1(config)# router isis 1
r1(config-router)# no advertise-high-metrics
r1(config-router)# end
r1# show isis summary
...
Area 1:
Net: 49.0001.1720.1700.0002.00
TX counters per PDU type:
L2 IIH: 1
P2P IIH: 45
LSP RXMT: 0
RX counters per PDU type:
Advertise high metrics: Disabled
Level-2:
...
r1#
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
New configuration to pad ISIS hello packets during adjacency formation only.
Signed-off-by: Diogo Oliveira <14191454+dorDiogo@users.noreply.github.com>
Add the support of Extended Admin-Group (RFC7308) to the zebra interface
link-params Traffic-Engineering context.
Extended admin-groups can be configured with the affinity-map:
> affinity-map blue bit-position 221
> int eth-rt1
> link-params
> affinity blue
> exit-link-params
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Some route-distinguisher notation is not supported today.
route-map rmap permit 1
match evpn rd 1.1:1
match evpn rd 0.65000:1
!
Add support for this.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some route-distinguisher combinations were not possible under
route-maps:
route-map rmap permit 1
match evpn rd 65540:44
match evpn rd 1.2.3.4:44
match evpn rd 2000000:44
Do not use the ietf definition for route-distinguisher by overriding
a new definition in bgp-route-map.yang itself. When the BGP northbound
API will be done, this route-distinguisher definition will have to
be used too.
Fixes: ("48cb7ea99d10") bgpd: North-bound implementation for bgp rmaps
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the affinity-map global command to zebra. The syntax is:
> affinity-map NAME bit-position (0-1023)
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
YANG files get to keep their license boilerplate in addition to the SPDX
header, since they are likely to be copied around individually.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The files converted in this commit either had some random misspelling or
formatting weirdness that made them escape automated replacement, or
have a particularly "weird" licensing setup (e.g. dual-licensed.)
This also marks a bunch of "public domain" files as SPDX License "NONE".
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Parallel build may be executing another copy of embedmodel.py at the
same time, with both getting "False" on the isdir check, and then both
trying to mkdir - one of which will error out.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Define a generic BFD monitoring group template and use it to add support
for static route monitoring.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This commit adds a new option to control whether a VRRPv3 group
accepts / computes its checksum with a prepended IPv4 pseudoheader.
This should improve interoperability with other devices.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
Before:
r1# conf
r1(config)# router isis <area-tag>
r1(config-router)# set-overload-bit
<cr>
r1(config-router)# end
After:
r1# conf
r1(config)# router isis <area-tag>
r1(config-router)# set-overload-bit
<cr>
on-startup Set overload bit on startup
r1(config-router)# set-overload-bit on-startup
(0-86400) Set overload time in seconds
r1(config-router)# set-overload-bit on-startup 300
r1(config-router)# end
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
When a route imported from l3vpn is analysed, the nexthop from default
VRF is looked up against a valid MPLS path. Generally, this is done on
backbones with a MPLS signalisation transport layer like LDP. Generally,
the BGP connection is multiple hops away. That scenario is already
working.
There is case where it is possible to run L3VPN over GRE interfaces, and
where there is no LSP path over that GRE interface: GRE is just here to
tunnel MPLS traffic. On that case, the nexthop given in the path does not
have MPLS path, but should be authorized to convey MPLS traffic provided
that the user permits it via a configuration command.
That commit introduces a new command that can be activated in route-map:
> set l3vpn next-hop encapsulation gre
That command authorizes the nexthop tracking engine to accept paths that
o have a GRE interface as output, independently of the presence of an LSP
path or not.
A configuration example is given below. When bgp incoming vpnv4 updates
are received, the nexthop of NLRI is 192.168.0.2. Based on nexthop
tracking service from zebra, BGP knows that the output interface to reach
192.168.0.2 is r1-gre0. Because that interface is not MPLS based, but is
a GRE tunnel, then the update will be using that nexthop to be installed.
interface r1-gre0
ip address 192.168.0.1/24
exit
router bgp 65500
bgp router-id 1.1.1.1
neighbor 192.168.0.2 remote-as 65500
!
address-family ipv4 unicast
no neighbor 192.168.0.2 activate
exit-address-family
!
address-family ipv4 vpn
neighbor 192.168.0.2 activate
neighbor 192.168.0.2 route-map rmap in
exit-address-family
exit
!
router bgp 65500 vrf vrf1
bgp router-id 1.1.1.1
no bgp network import-check
!
address-family ipv4 unicast
network 10.201.0.0/24
redistribute connected
label vpn export 101
rd vpn export 444:1
rt vpn both 52:100
export vpn
import vpn
exit-address-family
exit
!
route-map rmap permit 1
set l3vpn next-hop encapsulation gre
exit
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
