Invalid NEXT_HOP attribute for OSPF known route
Hello, every year or then bird is putting me into the Invalid NEXT_HOP message. TL;DR: Why does bird on router1+router2 refuse the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 via 2a0a:e5c0::225:90ff:fe1e:3e62 even though router1+router2 know how to reach 2a0a:e5c0::/64 via fe80::20d:b9ff:fe57:2f91 by means of ospf? In detail: router1, router2 are peered to apu-router1,apu-router2 via OSPF + BGP. apu-router1,apu-router2 are peered to a set of kubernetes hosts. The goal is to have router1 + router2 import the routes sent by the kubernetes hosts: router1 router2---------| | \ | | | \ | | | \ | | apu-router1 apu-router2 | . | . | |-------------------------- . . [ kubernetes cluster via apu-routers ] The problem: router1+router reject the routes with: Dec 14 20:33:51 router1 daemon.err bird: apu_router1_place5_ungleich_ch_v6: Invalid NEXT_HOP attribute The setup: router1, router2, apu-router1, apu-router2 = ASN209898 kubernetes hosts = ASN65533 kubernetes peers with apu-routers only. The routes: Kubernetes announces parts of 2a0a:e5c0:0:12::/64 and 2a0a:e5c0:0:13::/64, for instance the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122. Kubernetes nodes live in 2a0a:e5c0::/64. apu-routers have a leg in 2a0a:e5c0::/64, via eth1.2. They reach the cluster directly. They have the routes. routers1+2 receive the route for 2a0a:e5c0::/64 via ospf: bird> show route 2a0a:e5c0::/64 Table master6: 2a0a:e5c0::/64 unicast [ospf6 17:08:18.515] * I (150/20) [0.0.0.47] via fe80::20d:b9ff:fe57:2f91 on bond0.8 Thus routers *can* reach the kubernetes cluster. The apu-routers: - They import the route [0] - They export the route to the routers [1] The routers: - print 4x the Invalid NEXT_HOP attribute, once per exported kubernetes network - They ignore the 4 routes [2] Question: why does bird on the routers not accept the routes? Or is there a different problem I am not seeing? Aside from that, shouldn't bird on the apu-routers set itself as nexthop for the kubernetes routes? Any help appreciated. Best regards, Nico [0] [20:29] apu-router2.place5:~# birdc show route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 BIRD 2.0.8 ready. Table master6: 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 unicast [k8s_p5_1_4 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:3e74] * (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_3 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1a:d680] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_5 19:16:10.909] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_1 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1a:d682] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_2 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:3e64] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_6 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:62d6] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 [20:42] apu-router2.place5:~# [1] [20:43] apu-router2.place5:~# birdc show protocol all router1_place5_ungleich_ch_v6 BIRD 2.0.8 ready. Name Proto Table State Since Info router1_place5_ungleich_ch_v6 BGP --- up 20:29:06.203 Established BGP state: Established Neighbor address: 2a0a:e5c0:1:8::3 Neighbor AS: 209898 Local AS: 209898 Neighbor ID: 147.78.195.249 Local capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:1:8::47 Hold timer: 175.206/240 Keepalive timer: 53.629/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: REJECT Output filter: ungleich_networks_no_igp Routes: 0 imported, 6 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 98 0 98 0 0 Import withdraws: 3 0 --- 3 0 Export updates: 35 0 29 --- 6 Export withdraws: 0 --- --- --- 0 BGP Next hop: 2a0a:e5c0:1:8::47 fe80::20d:b9ff:fe49:a705 [2] bird> show protocol all apu_router2_place5_ungleich_ch_v6 Name Proto Table State Since Info apu_router2_place5_ungleich_ch_v6 BGP --- up 20:29:06.189 Established BGP state: Established Neighbor address: 2a0a:e5c0:1:8::47 Neighbor AS: 209898 Local AS: 209898 Neighbor ID: 0.0.0.47 Local capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:1:8::1 Hold timer: 157.409/240 Keepalive timer: 45.770/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ungleich_networks Output filter: ungleich_networks_no_igp Routes: 2 imported, 101 exported, 1 preferred Route change stats: received rejected filtered ignored accepted Import updates: 2 0 0 0 2 Import withdraws: 4 0 --- 4 0 Export updates: 140674 8 140565 --- 101 Export withdraws: 334 --- --- --- 0 BGP Next hop: 2a0a:e5c0:1:8::1 fe80::a236:9fff:fe08:a780 -- Sustainable and modern Infrastructures by ungleich.ch
On Tue, Dec 14, 2021 at 08:35:48PM +0100, Nico Schottelius wrote:
Hello,
every year or then bird is putting me into the Invalid NEXT_HOP message.
Hello Yes, this is kind of confusing error message (as i noted in response to Simon Ruderich).
TL;DR: Why does bird on router1+router2 refuse the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 via 2a0a:e5c0::225:90ff:fe1e:3e62
even though router1+router2 know how to reach 2a0a:e5c0::/64 via fe80::20d:b9ff:fe57:2f91 by means of ospf?
Note that in gateway-recursive mode, the fact of whether reachability is known is not relevant for 'Invalid NEXT_HOP' message. If it is unreachable, then the route would be accepted as 'unreachable' and changes to reachable if reachability is changed. It is usually some other issue like zero or local IP address.
In detail:
router1, router2 are peered to apu-router1,apu-router2 via OSPF + BGP.
apu-router1,apu-router2 are peered to a set of kubernetes hosts.
The goal is to have router1 + router2 import the routes sent by the kubernetes hosts:
router1 router2---------| | \ | | | \ | | | \ | | apu-router1 apu-router2 | . | . | |-------------------------- . . [ kubernetes cluster via apu-routers ]
The problem: router1+router reject the routes with:
Dec 14 20:33:51 router1 daemon.err bird: apu_router1_place5_ungleich_ch_v6: Invalid NEXT_HOP attribute
The setup:
router1, router2, apu-router1, apu-router2 = ASN209898 kubernetes hosts = ASN65533 kubernetes peers with apu-routers only.
So the BGP link between kubernetes and APU-ROUTER is EBGP, while between APU-ROUTER and ROUTER is IBGP? I expect it is in multihop / gateway-recursive mode, as it is default for IBGP?
The routes: Kubernetes announces parts of 2a0a:e5c0:0:12::/64 and 2a0a:e5c0:0:13::/64, for instance the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122.
Kubernetes nodes live in 2a0a:e5c0::/64.
apu-routers have a leg in 2a0a:e5c0::/64, via eth1.2. They reach the cluster directly. They have the routes.
routers1+2 receive the route for 2a0a:e5c0::/64 via ospf:
bird> show route 2a0a:e5c0::/64 Table master6: 2a0a:e5c0::/64 unicast [ospf6 17:08:18.515] * I (150/20) [0.0.0.47] via fe80::20d:b9ff:fe57:2f91 on bond0.8 The apu-routers: - They import the route [0]
Could you show 'show route all' on apu-router for failed routes to see their BGP_NEXT_HOP attribute? And also ideally tcpdump output to see BGP_NEXT_HOP as sent from apu-router to router?
- They export the route to the routers [1]
Could you also show 'show protocol all' for the session from apu-router to the kubernetes hosts?
The routers: - print 4x the Invalid NEXT_HOP attribute, once per exported kubernetes network - They ignore the 4 routes [2]
Question: why does bird on the routers not accept the routes? Or is there a different problem I am not seeing? Aside from that, shouldn't bird on the apu-routers set itself as nexthop for the kubernetes routes?
Not, because sending it to routerx over IBGP link, where BGP_NEXT_HOP is kept unmodified by default (unless 'next hop self' option is used). It might be an issue related to IPv6 dual next-hops (global and link-local), where global is empty. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> writes:
Yes, this is kind of confusing error message (as i noted in response to Simon Ruderich).
If there is one thing I'd suggest to improve first: print out the specific route and the next_hop - this would already help so much to debug the issue.
In detail:
router1, router2 are peered to apu-router1,apu-router2 via OSPF + BGP.
apu-router1,apu-router2 are peered to a set of kubernetes hosts.
The goal is to have router1 + router2 import the routes sent by the kubernetes hosts:
router1 router2---------| | \ | | | \ | | | \ | | apu-router1 apu-router2 | . | . | |-------------------------- . . [ kubernetes cluster via apu-routers ]
The problem: router1+router reject the routes with:
Dec 14 20:33:51 router1 daemon.err bird: apu_router1_place5_ungleich_ch_v6: Invalid NEXT_HOP attribute
The setup:
router1, router2, apu-router1, apu-router2 = ASN209898 kubernetes hosts = ASN65533 kubernetes peers with apu-routers only.
So the BGP link between kubernetes and APU-ROUTER is EBGP, while between APU-ROUTER and ROUTER is IBGP?
Correct.
I expect it is in multihop / gateway-recursive mode, as it is default for IBGP?
It's in direct mode for all links, as the APU-ROUTERS have physical links inside the kubernetes cluster as well as physical connection to the ROUTER.
The routes: Kubernetes announces parts of 2a0a:e5c0:0:12::/64 and 2a0a:e5c0:0:13::/64, for instance the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122.
Kubernetes nodes live in 2a0a:e5c0::/64.
apu-routers have a leg in 2a0a:e5c0::/64, via eth1.2. They reach the cluster directly. They have the routes.
routers1+2 receive the route for 2a0a:e5c0::/64 via ospf:
bird> show route 2a0a:e5c0::/64 Table master6: 2a0a:e5c0::/64 unicast [ospf6 17:08:18.515] * I (150/20) [0.0.0.47] via fe80::20d:b9ff:fe57:2f91 on bond0.8 The apu-routers: - They import the route [0]
Could you show 'show route all' on apu-router for failed routes to see their BGP_NEXT_HOP attribute? And also ideally tcpdump output to see BGP_NEXT_HOP as sent from apu-router to router?
bird> show route all 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 Table master6: 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 unicast [k8s_p5_1_6 2021-12-14 from 2a0a:e5c0::225:90ff:fe1e:3e74] * (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 unicast [k8s_p5_1_5 2021-12-14 from 2a0a:e5c0::225:90ff:fe1a:d680] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 unicast [k8s_p5_1_2 2021-12-14] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 unicast [k8s_p5_1_1 2021-12-14 from 2a0a:e5c0::225:90ff:fe1a:d682] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 unicast [k8s_p5_1_3 2021-12-14 from 2a0a:e5c0::225:90ff:fe1e:3e64] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 unicast [k8s_p5_1_4 2021-12-14 from 2a0a:e5c0::225:90ff:fe1e:62d6] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 Type: BGP univ BGP.origin: IGP BGP.as_path: 65533 BGP.next_hop: 2a0a:e5c0::225:90ff:fe1e:3e62 BGP.local_pref: 100 Pcap is attached as well.
- They export the route to the routers [1]
Could you also show 'show protocol all' for the session from apu-router to the kubernetes hosts?
bird> show protocols ... k8s_p5_1_1 BGP --- up 2021-12-14 Established k8s_p5_1_2 BGP --- up 2021-12-14 Established k8s_p5_1_3 BGP --- up 2021-12-14 Established k8s_p5_1_4 BGP --- up 2021-12-14 Established k8s_p5_1_5 BGP --- up 2021-12-14 Established k8s_p5_1_6 BGP --- up 2021-12-14 Established ... bird> show protocols all k8s_p5_1_6 Name Proto Table State Since Info k8s_p5_1_6 BGP --- up 2021-12-14 Established BGP state: Established Neighbor address: 2a0a:e5c0::225:90ff:fe1e:3e74 Neighbor AS: 65533 Local AS: 209898 Neighbor ID: 77.29.68.245 Local capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart Restart time: 120 AF supported: ipv6 AF preserved: 4-octet AS numbers ADD-PATH RX: ipv6 TX: ipv6 Enhanced refresh Long-lived graceful restart Session: external AS4 Source address: 2a0a:e5c0::46 Hold timer: 158.633/240 Keepalive timer: 53.250/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ungleich_networks_no_igp Output filter: REJECT Routes: 4 imported, 0 exported, 4 preferred Route change stats: received rejected filtered ignored accepted Import updates: 4 0 0 0 4 Import withdraws: 0 0 --- 0 0 Export updates: 43 6 37 --- 0 Export withdraws: 0 --- --- --- 0 BGP Next hop: 2a0a:e5c0::46 fe80::20d:b9ff:fe57:2f91
The routers: - print 4x the Invalid NEXT_HOP attribute, once per exported kubernetes network - They ignore the 4 routes [2]
Question: why does bird on the routers not accept the routes? Or is there a different problem I am not seeing? Aside from that, shouldn't bird on the apu-routers set itself as nexthop for the kubernetes routes?
Not, because sending it to routerx over IBGP link, where BGP_NEXT_HOP is kept unmodified by default (unless 'next hop self' option is used).
Correct, sorry for my confusion. Actually setting the next hop self does to some degree fix the problem, with the usual disadvantage of rewriting the attribute. Curious to what we are running into here. For reference the bgp configuration sections:
From the routers:
-------------------------------------------------------------------------------- protocol bgp apu_router1_place5_ungleich_ch_v6 { local as 209898; neighbor 2a0a:e5c0:1:8::46 as 209898; direct; ipv6 { # What we accept from this protocol -> others send us import filter ungleich_networks; # What we export into this protocol -> what we send export filter ungleich_networks_no_igp; }; # Highest preference on internal traffic default bgp_local_pref pref_normal; } --------------------------------------------------------------------------------
From the apu-routers:
protocol bgp router1_place5_ungleich_ch_v6 { local as 209898; neighbor 2a0a:e5c0:1:8::3 as 209898; direct; ipv6 { # What we accept from this protocol -> others send us import none; # What we export into this protocol -> what we send export filter ungleich_networks_no_igp; }; # Highest preference on internal traffic default bgp_local_pref pref_normal; } protocol bgp k8s_p5_1_v6 { local as 209898; neighbor range 2a0a:e5c0:0::/64 as 65533; dynamic name "k8s_p5_1_"; ipv6 { # What we accept from this protocol -> others send us import filter ungleich_networks_no_igp; # What we export into this protocol -> what we send export none; }; # Highest preference on internal traffic default bgp_local_pref pref_normal; } -------------------------------------------------------------------------------- I actually just realised that the "k8s_p5_1_v6" protocol did not have the direct statement, however adding it does not change the situation (probably because bird detects it as a direct link anyway). Best regards from the snowy mountains, Nico -- Sustainable and modern Infrastructures by ungleich.ch
On Thu, Dec 16, 2021 at 02:37:00PM +0100, Nico Schottelius wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
Yes, this is kind of confusing error message (as i noted in response to Simon Ruderich).
If there is one thing I'd suggest to improve first: print out the specific route and the next_hop - this would already help so much to debug the issue.
Agreed.
So the BGP link between kubernetes and APU-ROUTER is EBGP, while between APU-ROUTER and ROUTER is IBGP?
Correct.
I expect it is in multihop / gateway-recursive mode, as it is default for IBGP?
It's in direct mode for all links, as the APU-ROUTERS have physical links inside the kubernetes cluster as well as physical connection to the ROUTER.
This is likely the issue. In BIRD, relations between default values are: EBGP/IBGP -> direct / multihop -> gateway direct/recursive. So, by changing link mode to direct, you implicitly changed gateway mode from recursive to direct. In gateway direct mode, the next hop is not resolved through routing table, just through interface ranges. And if not found, it is rejected with 'Invalid next hop', so having OSPF route is irrelevant. But because link is IBGP, the original (indirect) next hop is there. Note that whole direct / gateway direct mode is designed primarily for EBGP. It can be used with IBGP on flat topology and 'next hop self' on IBGP links (so IGP/OSPF routes are not needed). Technically you can configure direct mode, and also 'gateway recursive' in channels. That should work, although it is probably less tested combination.
I actually just realised that the "k8s_p5_1_v6" protocol did not have the direct statement, however adding it does not change the situation (probably because bird detects it as a direct link anyway).
That is EBGP, which is direct by default (and that is OK). The issue is direct on IBGP. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> writes:
I expect it is in multihop / gateway-recursive mode, as it is default for IBGP?
It's in direct mode for all links, as the APU-ROUTERS have physical links inside the kubernetes cluster as well as physical connection to the ROUTER.
This is likely the issue. In BIRD, relations between default values are:
Removing the direct statement from the iBGP sessions indeed fixes the problem. So technically speaking, what is the disadvantage/drawback of avoiding the "direct" statement everywhere? We have so far added it whenever the connection was in the same network segment (hence: direct), but if it is enabled for eBGP by default (makes sense) and it does not "help" in the iBGP case, should we ever use it?
EBGP/IBGP -> direct / multihop -> gateway direct/recursive.
So, by changing link mode to direct, you implicitly changed gateway mode from recursive to direct.
In gateway direct mode, the next hop is not resolved through routing table, just through interface ranges. And if not found, it is rejected with 'Invalid next hop', so having OSPF route is irrelevant. But because link is IBGP, the original (indirect) next hop is there.
I understand the code path logic, but I don't understand the "configuration logic". Or as said above: does it ever make sense to apply direct explicitly?
I actually just realised that the "k8s_p5_1_v6" protocol did not have the direct statement, however adding it does not change the situation (probably because bird detects it as a direct link anyway).
That is EBGP, which is direct by default (and that is OK). The issue is direct on IBGP.
Thanks for clarfication! Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
On Thu, Dec 16, 2021 at 04:41:09PM +0100, Nico Schottelius wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
I expect it is in multihop / gateway-recursive mode, as it is default for IBGP?
It's in direct mode for all links, as the APU-ROUTERS have physical links inside the kubernetes cluster as well as physical connection to the ROUTER.
This is likely the issue. In BIRD, relations between default values are:
Removing the direct statement from the iBGP sessions indeed fixes the problem. So technically speaking, what is the disadvantage/drawback of avoiding the "direct" statement everywhere? We have so far added it whenever the connection was in the same network segment (hence: direct), but if it is enabled for eBGP by default (makes sense) and it does not "help" in the iBGP case, should we ever use it?
It has some minor advantages (like BGP is enabled immediately after iface with neighbor address appears, BGP state can depend on layer-2 link state, you can use TTL security more reliably, you can run BGP over link-local addresses).
EBGP/IBGP -> direct / multihop -> gateway direct/recursive.
So, by changing link mode to direct, you implicitly changed gateway mode from recursive to direct.
In gateway direct mode, the next hop is not resolved through routing table, just through interface ranges. And if not found, it is rejected with 'Invalid next hop', so having OSPF route is irrelevant. But because link is IBGP, the original (indirect) next hop is there.
I understand the code path logic, but I don't understand the "configuration logic". Or as said above: does it ever make sense to apply direct explicitly?
Yes, if you have flat topology (all EBGP routers connected to shared layer-2 segment), do not run IGP/OSPF, and use 'next hop self' on all IBGP links, then enabling 'direct / gateway direct' can make sense compared to regular multihop IBGP with recursive next hop resolution. For example, in your case, you can decide to drop OSPF, propagate 2a0a:e5c0::/64 also through BGP and enable 'next hop self' on IBGP sessions. Then enabling 'direct' would make sense. But in your current setup i would probably recommend to use regular multihop IBGP. Also note the reverse case for this option - switching EBGP to multihop (which is used mostly in diagnostic setups / route collectors). One could argue that perhaps configuration logic: EBGP/IBGP -> direct / multihop EBGP/IBGP -> gateway direct/recursive would make more sense (i.e. switching IBGP to direct would not implicitly enable gatewa direct mode), but it makes less sense for the reverese case - if you switch EBGP to multihop then you do not want gateway direct. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Nico Schottelius -
Ondrej Zajicek