Looking good so far. Started with no IP on eth0 and then added IP to eth0: S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:01:45 S>* 10.1.1.0/24 [1/0] via 10.1.2.1, eth0, 00:00:40 C>* 10.1.2.0/24 is directly connected, eth0, 00:00:40 Removed IP from eth0: S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:02:08 S> 10.1.1.0/24 [1/0] via 10.1.2.1 (recursive), 00:00:02 * unreachable, 00:00:02 Added IP to eth0 again: S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:02:28 S>* 10.1.1.0/24 [1/0] via 10.1.2.1, eth0, 00:00:02 C>* 10.1.2.0/24 is directly connected, eth0, 00:00:02 On 6/25/19 8:40 AM, Donald Sharp wrote:
Patrick -
I just submitted: https://github.com/FRRouting/frr/pull/4602
I believe it will get static route handling `correct` now.
donald
On Sun, Jun 23, 2019 at 6:36 AM Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
In staticd.conf:
ip route 10.1.1.0/24 10.1.2.1 ip route 10.1.0.0/16 Null0
Just noticed the route appears fine if the route is reachable when staticd starts but not if it isn't.
For example, 10.1.2.25/24 on eth0 when staticd is started:
S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:00:15 S>* 10.1.1.0/24 [1/0] via 10.1.2.1, eth0, 00:00:15 C>* 10.1.2.0/24 is directly connected, eth0, 00:00:15
Take 10.1.2.25/24 off eth0 and no change even though the route should be removed from kernel.
With no IP on eth0 when staticd is started:
S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:00:03 S> 10.1.1.0/24 [1/0] via 10.1.2.1 (recursive), 00:00:03 * unreachable, 00:00:03
Put 10.1.2.25/24 on eth0 and no change even though the route should be added to the kernel.
S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:01:05 S> 10.1.1.0/24 [1/0] via 10.1.2.1 (recursive), 00:01:05 * unreachable, 00:01:05 C>* 10.1.2.0/24 is directly connected, eth0, 00:00:02
On 6/22/19 11:34 PM, Donald Sharp wrote:
Patrick -
I'm getting a slightly different result than you:
S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:00:45 S>* 10.1.1.0/24 [1/0] via 10.1.2.1, dummy99, 00:00:04 C>* 10.1.2.0/24 is directly connected, dummy99, 00:01:05
Can you give me a bit more details about how you did this exactly? This looks like some sort of order of events issue that I need to fix.
doanld
On Sat, Jun 22, 2019 at 9:33 PM Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
FRR 7.1 CentOS 7.6.1810
With this in staticd.conf
ip route 10.1.0.0/16 Null0
everything in 10.1.0.0/16 gets blackholed even if there is a more specific route. Is this normal behaviour? If so, is there a way to turn off recursive?
In vtysh:
# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route
S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:07:41 S> 10.1.1.0/24 [1/0] via 10.1.2.1 (recursive), 00:07:41 * unreachable, 00:07:41 C>* 10.1.2.0/24 is directly connected, eth0, 00:06:59
From bash:
# ip r s|grep hole blackhole 10.1.0.0/16 proto 196 metric 20 blackhole 10.1.1.0/24 proto 196 metric 20
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog