When you set the isis mtu to 200, isis ends up in a infinite loop
trying to fragment the tlv's.
Specifically ( for me ) the extended reachability function
for packing pack_item_extended_reach requires 11 + ISIS_SUBTLV_MAX_SIZE
room in the packet. Which is 180 bytes. At this point we have
174 bytes that we can write into a packet.
I created this by modifying the isis-topo1 topology to all
the isis routers to have a lsp-mtu of 200 and immediately
saw the crash.
Effectively the pack_items_ function had no detection for
when a part of the next bit it was writing into the stream
could not even fit and it would go into an infinite loop
allocating ~800 bytes at a time. This would cause the
router to run out of memory very very fast and the OOM
detector would kill the process.
Modify the code to notice that we have insufficient space to
even write any data into the stream.
I suspect that pack_item_extended_reach could also be optimized
to figure out exactly how much space is needed. But I also
think we need this protection in the function if this ever
happens again.
I also do not understand the use case of saying the min mtu is
200.
Fixes: #8289
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue:
User is allowed to configure only hello without hold timer but when undo
config, the hold timer is mandatory as shown below:
FRR-4(config-if)# ip pim hello 10
<cr>
(1-180) Time in seconds for Hold Interval
FRR-4(config-if)# ip pim hello 10
FRR-4(config-if)# no ip pim hello 10
(1-180) Time in seconds for Hold Interval
FRR-4(config-if)# no ip pim hello 10
% Command incomplete: no ip pim hello 20
Fix:
Making the hold timer as optional when undo config.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Also included display of hold time in CLI 'show ip pim int <intf>' cmd
and json commands.
Issue:
PIM neighbor not coming up if hold time is less than hello timer
since hello is sent every 4 sec and hold is 1 sec,
because of this nbr is flapping
Fix:
Do not allow configuration of hold timer less than hello timer
Also reset the value of hold timer to 3.5 times to hello whenever
only hello is modified so that the relationship holds good.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When the ospf6 daemon goes down, it originates MAX_AGE
LSAs for all the self-originated LSAs so that it gets
flushed from the neighbor's database. But the link-LSAs
are not getting MAX_AGE.
Set the self-originated link-LSAs age to MAX_AGE and
flood it
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
This command will trigger the OSPF forwarding address suppression in
translated type-5 LSAs, causing a NSSA ABR to use 0.0.0.0 as a forwarding
address instead of copying the address from the type-7 LSA
Example: In a topology like: R1 --- R2(ABR) --- R3(ASBR)
R3 is announcing a type-7 LSA that is translated to type-5 by the R2 ABR.
The forwarding address in the type-5 is by default copied from the type-7
r1# sh ip os da external
AS External Link States
LS age: 6
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000001
Checksum: 0xcf99
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.23.3 <--- address copied from type-7 lsa
External Route Tag: 0
r2# sh ip os database
NSSA-external Link States (Area 0.0.0.1 [NSSA])
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.23.3 8 0x80000001 0x431d E2 3.3.3.3/32 [0x0]
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.25.2 0 0x80000001 0xcf99 E2 3.3.3.3/32 [0x0]
r2# conf t
r2(config)# router ospf
r2(config-router)# area 1 nssa suppress-fa
r2(config-router)# exit
r2(config)# exit
r2# sh ip os database
NSSA-external Link States (Area 0.0.0.1 [NSSA])
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.23.3 66 0x80000001 0x431d E2 3.3.3.3/32 [0x0]
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
3.3.3.3 10.0.25.2 16 0x80000002 0x0983 E2 3.3.3.3/32 [0x0]
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 34
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000002
Checksum: 0x0983
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0 <--- address set to 0
External Route Tag: 0
r2# conf t
r2(config)# router ospf
r2(config-router)# no area 1 nssa suppress-fa
r2(config-router)# exit
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 1
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000003
Checksum: 0xcb9b
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0 <--- address set to 0
External Route Tag: 0
r2# conf t
r2(config)# router ospf
r2(config-router)# no area 1 nssa suppress-fa
r2(config-router)# exit
r1# sh ip os da external
OSPF Router with ID (11.11.11.11)
AS External Link States
LS age: 1
Options: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: AS-external-LSA
Link State ID: 3.3.3.3 (External Network Number)
Advertising Router: 10.0.25.2
LS Seq Number: 80000003
Checksum: 0xcb9b
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.23.3 <--- address copied from type-7 lsa
External Route Tag: 0
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
This command is currently useful only for developers.
Let's hide it to not confuse end users by having both
"show runnning-config" and "show configuration running".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Before the transition of prefix-lists to northbound, this setting
controlled whether sequence numbers were displayed in the config.
After the transition, sequence numbers are always displayed in the
configuration, and this command only controls the output of the show
commands, which is not very useful. This command is not even shown in
the config anymore.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Make the local buffer offered to printfrr extension tokens
bigger; existing size wasn't quite enough for some of the
more elaborate struct prefix types.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Instead of using bgp_get_default which refers to operational state, we
can check existence of the default node using only candidate config.
The same thing is done in "no router bgp" command.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When "bgp bestpath peer-type multipath-relax" is enabled, multipaths
with both eBGP and iBGP learned routes may exist. It is not desirable
for the iBGP next hops to be discarded from the FIB because they are not
directly connected. When publishing a nexthop group to zebra, the
ZEBRA_FLAG_ALLOW_RECURSION flag is normally not set when the best path
is eBGP; when "bgp bestpath aspath multipath-relax" is configured, the
flag will now be set if any paths are from iBGP peers. This leaves
all-eBGP multipaths still requiring nexthops over connected routes.
Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
This new BGP configuration is akin to "bgp bestpath aspath
multipath-relax". When applied, paths learned from different peer types
will be eligible to be considered for multipath (ECMP). Paths from all
of eBGP, iBGP, and confederation peers may be included in multipaths
if they are otherwise equal cost.
This change preserves the existing bestpath behavior of step 10's result
being returned, not the result from steps 8 and 9, in the case where
both 8+9 and 10 determine a winner.
Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
1. When VNI export RT changes, for each local es_evi, update local
EAD/ES and EAD/EVI routes and advertise.
2. When VNI import RT changes, uninstall all type-1 routes imported in
the VNI and import routes carrying the updated RT.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Move `bgp_peer_config_apply` outside `bgp_peer_configure_bfd` (and
document it) so we only call the session installation once with one
set of timers. It also makes all calls of that function
equal (e.g. always calls `bgp_peer_config_apply` afterwards).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Remove old BFD API usage and replace it with the new one.
Highlights:
- More shared code: the daemon gets notified with callbacks instead of
having to roll its own code to find the notified sessions.
- Less code to integrate with BFD.
- Remove hidden commands to configure single / multi hop. Use
protocol data instead.
BGP can determine if a peer is single/multi hop according to the
following criteria:
a. If the IP address is a link-local address (single hop)
b. The network is shared with peer (single hop)
c. BGP is configured for eBGP multi hop / TTL security (multi hop)
- Respect the configuration hierarchy:
a. Peer configuration take precendence over peer-group
configuration.
b. When peer group configuration is removed, reset peer
BFD configurations to defaults (unless peer had specific
configs).
Example:
neighbor foo peer-group
neighbor foo bfd profile X
neighbor 192.168.0.2 peer-group foo
neighbor 192.168.0.2 bfd
! If peer-group is removed the profile configuration gets
! removed from peer 192.168.0.2, but BFD will still enabled
! because of the neighbor specific bfd configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The BFD function `bgp_bfd_is_peer_multihop` will no longer exist and now
both code paths are equal.
Longer explanation:
Cumulus was previously using the BFD function to help determine whether a
peer is multi hop or not, because there is a configuration to set BFD
to use single or multi hop.
Current BFD code can automatically pick between single/multi hop by
using the protocol information and so it is a good idea to have that
tested/used than relying on yet another duplicated information.
(BFD extracts the TTL information from protocol and selects
single/multi hop based on that)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
New BFD protocol integration API with abstractions to fix most common
protocol integration errors:
- Set address family together with the source/destination addresses
- Set the TTL together with the single/multi hop option
- Set/unset profile/interface easily
- Keep the arguments so we don't have to rebuild them every time
- Install/uninstall functions that keep track of current state so the
daemon doesn't have to
- Reinstall when critical configuration changes (address, multi hop
etc...)
- Reconfigure BFD when the daemon restarts automatically
- Automatically calls the user defined callback for session update
- Shutdown handler for all protocols
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
