A few optimizations for bfd NB:
- Remove unuseful checks for parameters with the same values
- Replace checking values of bfd parameters with YANG's "range"
- Append "required-echo-receive-interval" with 0 for it can be disabled
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Introduces a topotest to validate proper AS-Path manipulation when using
"neighbor ... remove-private-AS".
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
In situations where remove-private-AS is configured for eBGP peers
residing in a private ASN, the peer's ASN was not being retained
in the AS-Path which can allow loops to occur. This was addressed
in a prior commit but it only addressed cases where the "replace-AS"
keyword was configured.
This commit ensures we retain the peer's ASN when using
"remove-private-AS" for eBGP peers in a private ASN regardless of other
keywords.
Setup:
=========
router bgp 4200000002
neighbor enp1s0 interface v6only remote-as external
neighbor enp6s0 interface v6only remote-as external
!
address-family ipv4 unicast
neighbor enp6s0 remove-private-AS
exit-address-family
ub18# show ip bgp sum | include 420000
BGP router identifier 100.64.0.111, local AS number 4200000002 vrf-id 0 <<<<< local asn 4200000002
ub20(enp1s0) 4 4200000001 22 22 0 0 0 00:00:57 1 1
ub20(enp6s0) 4 4200000001 21 22 0 0 0 00:00:57 0 1 <<<< peer asn 4200000001
ub18# show ip bgp | include 0.2
Default local pref 100, local AS 4200000002
*> 100.64.0.2/32 enp1s0 0 0 4200000001 4200000004 4200000005 4200000001 i
Before ("remote-private-AS" only):
=========
ub18# show ip bgp neighbors enp6s0 advertised-routes | include 100.64.0.2
*> 100.64.0.2/32 :: 0 i <<<<< empty as-path, no way to prevent loop
After ("remote-private-AS" only):
=========
ub18# show ip bgp neighbors enp6s0 advertised-routes | include 100.64.0.2
*> 100.64.0.2/32 :: 0 4200000001 4200000001 i <<<< retain peer's asn, breaks loop
Ticket: 2857047
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Opaque data takes up a lot of memory when there are a lot of routes on
the box. Given that this is just a cosmetic info, I propose to disable
it by default to not shock people who start using FRR for the first time
or upgrades from an old version.
Fixes#10101.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
XPATH_MAXLEN denotes the maximum length of an XPATH. It does not make
sense to allocate a buffer intended to contain an XPATH with a size
larger than the maximum allowable size of an XPATH. Consequently this PR
removes buffers that do this. Prints into these buffers are now checked
for overflow.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Here "new" is very puzzling. If new parameters with default values on peer
configuration node are set, they will not be used yet.
So just clarify it:
Only "non-default" values on peer configuration node are set, they can override
the conrresponding values from profile.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Just like other parameters of bfd, "minimum-ttl" should also have
a default value. Parameters with default value will not be displayed
in running configuration.
Additionly adjust the other "range" with double quotation marks.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Description:
This LSID alogithm added as per rcf2328 Appendex-E recommendation.
This applies only for AS-external lsas and summary lsas.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Problem:
During restarting frr.service, it throws annoying warnings:
Cannot stop bgpd(and others): pid file not found.
Root Cause:
During restarting process, systemd uses "stop", and watchfrr
uses "restart".
Yes, watchfrr using "restart" is to avoid systemd failing to stop.
But it should be quiet.
Fix:
During restarting service, suppress these warnings from watchfrr.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
```
exit1-debian-11(config-router)# neighbor 192.168.100.3 remote-as external
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# no neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor eth0 interface remote-as external
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# no neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
no neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The current maximum-prefix-out topo-test starts a configuration with a
maximum-prefix-out.
Test the application of new maximum-prefix-out value without clearing
the neighbor.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Abstract:
- The command "neighbor PEER maximum-prefix-out NUMBER" cannot be applied
without clearing the BGP neighbor.
- Apply the maximum-prefix-out value as soon as it is modified without
clearing the neighbor.
subgroup_update_packet() and subgroup_withdraw_packet() respectively
manages the announcement and withdrawal BGP message to the peer.
subgrp->scount counter counts the number of sent prefixes.
Before the patch, the maximum out prefix limitation was applied in
subgroup_update_packet() in order that subgrp->scount never exceeds the
limit. Setting a limit inferior to the effective number of sent prefix
did not result in sending any withdrawal message to reduce the number of
sent prefixes. Without clearing the BGP neighbor, the limitation only
applied to the announcement of new prefixes when the limitation was
over.
With the patch, the limitation is checked in subgroup_announce_check().
The function is intended to say whether a prefix has to be announced in
regards to the prefix-list, route-map... Now when a maximum-prefix-out
value is changed/removed, the neighbor AFI/SAFI table is re-parsed in
the same way as for the application of route-map, prefix-lists...
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Take into account the maximum-prefix-out value when calculating the
update-group hash.
Fixes: fde246e835 ("bgpd: Add an option to limit outgoing prefixes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add a thread_ignore_late_timer(struct thread *thread) function
that allows thread.c to ignore when timers are late to the party.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If a thread timer should have popped CPU_CONSUMED_CHECK
seconds in the past, and we are only handling it now. Consider
the thread starved and notice it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
==================
(rcv1)-----A----B---C
v3 enabled with src 90.0.0.1
|
(rcv2)--
v2 enable with src none
rcv1 sends the packet in INCLUDE mode, rcv2 sends the IGMPv2 report
and PIM convers this report into exclude mode.
As per the state machine the group structure was
getting added and deleted. As group gets deleted the mroute for 90.0.0.1
and recreated back.
This effects the end to end trafiic.
Root Cause Analysis:
====================
As per state machine
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
The above equations were getiing calulated for IP address
90.0.0.1 and 0.0.0.0
This results in group creation deletion.
Fix:
====
As per RFC 4604.
drop the exclude mode, IGMP reports, if destnation group is
SSM based.
EXCLUDE
mode does not apply to SSM addresses, and an SSM-aware router will
ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
range,
Signed-off-by: Abhishek N R <abnr@vmware.com>
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Problem Statement:
==================
(rcv1)-----A----B---C
v3 enabled with src 90.0.0.1
|
(rcv2)--
v3 enable with src none
rcv1 sends the packet in INCLUDE mode, rcv2 sends the IGMP report
in exclude mode. As per the state machine the group structure was
getting added and deleted. As group gets deleted the mroute for 90.0.0.1
and recreated back.
This effects the end to end trafiic.
Root Cause Analysis:
====================
As per state machine
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
The above equations were getiing calulated for IP address
90.0.0.1 and 0.0.0.0
This results in group creation deletion.
Fix:
====
As per RFC 4604.
drop the exclude mode, IGMP reports, if destnation group is
SSM based.
EXCLUDE
mode does not apply to SSM addresses, and an SSM-aware router will
ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
range.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Fixes#9720. When updating an ECMP inter-area route, we compute
a new route and check whether that already exists. If so, we keep the old
route and only update its nexthops. Previously, we merged the new route's
nexthops into the old one's, but this way, it's impossible to remove
nexthops from the old route, resulting in stale nexthops.
This commit fixes this by first removing all nexthops from the old route and
then copying all nexthops from the new route into it. If the new route has
fewer nexthops, the old one will have as well afterwards.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
BGP EVPN custom `union gw_addr` is basically the same thing as a common
`struct ipaddr` but it lacks the address family which is needed in some
cases.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This code is populating a temporary variable `add` instead of the attr.
Initially this variable was later copied to the attr but the copying was
erroneously deleted by 0a50c2481. Directly populate the attr to restore
the correct behavior.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Here we try to compare the new attr with the existing one but this call
compares the existing index with zero instead. attrhash_cmp already
compares indexes using overlay_index_same so this call is both wrong and
useless.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
