Force faster generation of lsp's and also cause the
networks to converge faster. All affected tests
run faster now.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The commit `bfdd: simplify and remove duplicated code` fixed a problem
that was causing the protocol configuration to override the user
configuration.
In this test case: the peer was configured to be disabled (default is
`shutdown`) and the test was expecting it to get activated (`no shutdown`)
when the protocol converged. I changed the peer default state to
`no shutdown`, however another way to get the same effect is to
configure the protocol to use a profile or don't configure a peer at all
(and use the defaults).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The tests work with the default settings of BFD meaning that bfdd is
able to recognize a 'down' link after ~900ms so a route recovery should
be visible in the RIB after 1 second.
In the current state only IPv4 is used (when using IPv6
autoconfiguration) within BFD, even though the recovery also affects
IPv6 routes. This is different to the current state of ospfd/ospf6d in
combination with BFD since both IPv4 and IPv6 sessions are used there.
The following topology is used:
+---------+
| |
eth-rt2 (.1) | RT1 | eth-rt3 (.1)
+----------+ 1.1.1.1 +----------+
| | | |
| +---------+ |
| |
| 10.0.2.0/24 |
| |
| eth-rt1 | (.2)
| 10.0.1.0/24 +----+----+
| | |
| | RT3 |
| | 3.3.3.3 |
| | |
(.2) | eth-rt1 +----+----+
+----+----+ eth-rt4 | (.1)
| | |
| RT2 | |
| 2.2.2.2 | 10.0.4.0/24 |
| | |
+----+----+ |
(.1) | eth-rt5 eth-rt3 | (.2)
| +----+----+
| | |
| | RT4 |
| | 4.4.4.4 |
| | |
| +----+----+
| 10.0.3.0/24 eth-rt5 | (.1)
| |
| |
| 10.0.5.0/24 |
| |
| +---------+ |
| | | |
+----------+ RT5 +----------+
eth-rt2 (.2) | 5.5.5.5 | eth-rt4 (.2)
| |
+---------+
Route recovery is tested on RT1. The focus here lies on the two
different routes to RT5. Link failures are generated by taking
down interfaces via the mininet Python interface on RT2 and RT3.
Hence routes are supposed to be adjusted to use RT3 when a link
failure happens on RT2 or vice versa.
Note that only failure recognition and recovery is "fast". BFD
does not monitor a link becoming available again.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
