Hello list, I am trying to understand where I might be going wrong in my implementation or understanding of the following setup. I have two servers in different locations, both of which are using exabgp to advertise the same /32 loopback to their nearest bird router over eBGP. The network is logically just a ring of 6 bird routers running OSPF and an iBGP full mesh. These /32 routes are then distributed via the iBGP mesh to the rest of the network. Both routes are identical in their attributes apart from the next-hop and router-id. They have the same MED and localpref. The next-hop routes are of course known from OSPF. The documentation states that "BGP depends on existing IGP routing table with AS-internal routes to determine immediate next hops for routes and to know their internal distances to boundary routers for the purpose of BGP route selection". However: When inspecting the available routes from one of my bird routers elsewhere on the network, I see one for which the next-hop OSPF cost is 20, and one where the cost is 30. Both routes still show the same MED, the same localpref, same as-path etc, but the route with the higher OSPF cost is always being installed. The only reason I can see for this route to be preferred is that the originating router has the lower router-id, but this check comes after the supposed IGP distance check in the route selection rules. So am I completely misunderstanding how this process works, or have I just done something wrong? Any advice would be greatly appreciated. Available routes for the /32: ------------------------- root@bird1:~# birdc show route all for 10.13.83.6 BIRD 1.4.5 ready. 10.13.83.6/32 via 10.13.83.246 on eth1.10 [BIRD3 2015-09-08 from 10.13.83.2] * (100/?) [AS65100i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65100 BGP.next_hop: 10.13.82.65 BGP.med: 100 BGP.local_pref: 100 via 10.13.83.233 on eth0.14 [BIRD6 2015-09-08 from 10.13.83.5] (100/?) [AS65100i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65100 BGP.next_hop: 10.13.81.73 BGP.med: 100 BGP.local_pref: 100 Installed routes to the next-hops: ------------------------- root@bird1:~# birdc show route all primary for 10.13.82.65 BIRD 1.4.5 ready. 10.13.82.64/27 via 10.13.83.246 on eth1.10 [PackOSPF 2015-08-05] * E2 (150/30/10000) [10.13.83.2] Type: OSPF-E2 unicast univ OSPF.metric1: 30 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.13.83.2 root@bird1:~# birdc show route all primary for 10.13.81.73 BIRD 1.4.5 ready. 10.13.81.64/27 via 10.13.83.233 on eth0.14 [PackOSPF 2015-08-24] * E2 (150/20/10000) [10.13.83.5] Type: OSPF-E2 unicast univ OSPF.metric1: 20 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.13.83.5 Adam Priestley Network Administrator Packnet Limitedt: +44 (0)161 660 2350 f: +44 (0)161 660 9825 e: adam@pack-net.co.uk w: http://www.pack-net.co.uk/ Registered Address: PACKNET LIMITED, Duplex 2, Ducie House 37 Ducie Street Manchester, M1 2JW COMPANY REG NO. 04920552
On Thu, Sep 10, 2015 at 10:40:22AM +0100, Adam Priestley wrote:
Hello list,
I am trying to understand where I might be going wrong in my implementation or understanding of the following setup.
The documentation states that "BGP depends on existing IGP routing table with AS-internal routes to determine immediate next hops for routes and to know their internal distances to boundary routers for the purpose of BGP route selection". However: When inspecting the available routes from one of my bird routers elsewhere on the network, I see one for which the next-hop OSPF cost is 20, and one where the cost is 30. Both routes still show the same MED, the same localpref, same as-path etc, but the route with the higher OSPF cost is always being installed.
The only reason I can see for this route to be preferred is that the originating router has the lower router-id, but this check comes after the supposed IGP distance check in the route selection rules. So am I completely misunderstanding how this process works, or have I just done something wrong? Any advice would be greatly appreciated.
Hello For BGP recursive routes, the (X/Y) in show route is priority / IGP metric. '?' means that IGP metric for some reason cannot be determined. This baffled me as otherwise the BGP routes use proper next hops from OSPF routes. I examined it and for some reason[*] BIRD does not accept OSPF type-2 external metric as IGP metric for the purpose of recursive route comparison. There are two solutions, either export that static routes to OSPF as type-1 external routes instead of type-2 external routes, or set the ipg_metric route attribute explicitly in OSPF import filters (e.g. 'igp_metric = ospf_metric1' would use ospf_metric1 always even for type-2 external route). [*] Probably because type-2 external routes have both type-2 metric and regular metric, both have 24-bit range and it would be problematic to compress that into 32-bit igp metric range. -- 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."
On 10 September 2015 at 12:03, Ondrej Zajicek <santiago@crfreenet.org> wrote:
I examined it and for some reason[*] BIRD does not accept OSPF type-2 external metric as IGP metric for the purpose of recursive route comparison. There are two solutions, either export that static routes to OSPF as type-1 external routes instead of type-2 external routes, or set the ipg_metric route attribute explicitly in OSPF import filters (e.g. 'igp_metric = ospf_metric1' would use ospf_metric1 always even for type-2 external route).
[*] Probably because type-2 external routes have both type-2 metric and regular metric, both have 24-bit range and it would be problematic to compress that into 32-bit igp metric range.
Hi Ondrej, Thanks for your assistance. I will try what you've suggested, but I'd just like to make sure I understand you. You mention static routes, but there are none in my configuration. OSPF is learning linknets and router loopbacks only, this particular /32 is only ever known to BGP. Are you saying that when OSPF is learning the linknets that ultimately provide the routes used for next-hop, I should be applying the 'igp_metric = ospf_metric1' filter? Thanks again. Adam Priestley Network Administrator Packnet Limitedt: +44 (0)161 660 2350 f: +44 (0)161 660 9825 e: adam@pack-net.co.uk w: http://www.pack-net.co.uk/ Registered Address: PACKNET LIMITED, Duplex 2, Ducie House 37 Ducie Street Manchester, M1 2JW COMPANY REG NO. 04920552
On Thu, Sep 10, 2015 at 02:21:36PM +0100, Adam Priestley wrote:
On 10 September 2015 at 12:03, Ondrej Zajicek <santiago@crfreenet.org> wrote:
I examined it and for some reason[*] BIRD does not accept OSPF type-2 external metric as IGP metric for the purpose of recursive route comparison. There are two solutions, either export that static routes to OSPF as type-1 external routes instead of type-2 external routes, or set the ipg_metric route attribute explicitly in OSPF import filters (e.g. 'igp_metric = ospf_metric1' would use ospf_metric1 always even for type-2 external route).
[*] Probably because type-2 external routes have both type-2 metric and regular metric, both have 24-bit range and it would be problematic to compress that into 32-bit igp metric range.
Hi Ondrej,
Thanks for your assistance. I will try what you've suggested, but I'd just like to make sure I understand you.
You mention static routes, but there are none in my configuration. OSPF is learning linknets and router loopbacks only, this particular /32 is only ever known to BGP. Are you saying that when OSPF is learning the linknets that ultimately provide the routes used for next-hop, I should be applying the 'igp_metric = ospf_metric1' filter?
I mean 10.13.82.64/27 on router 10.13.83.2 (or 10.13.81.64/27 on 10.13.83.5). These are E2 routes at discussed router, which means that they are exported to OSPF at 10.13.83.2 (10.13.83.5). I guessed static, but they could be from other protocol like direct. You could set 'ospf_metric1 = XXX' in export filter at their source router to export them as E1 routes with specified initial E1 metric instead of as E2 routes (default, with initial 10000 E2 metric) Or if these routes are direct routes at their source router (10.13.83.2 ...), you could configure stub/passive OSPF interfaces on appropriate interfaces and not export these routes (10.13.82.64/27 / 10.13.81.64/27) to OSPF as external routes. Hence, they would be propagated as OSPF internal routes. Or third possibility (but probably least appropriate), would be to keep these routes as E2, but setup 'igp_metric = ospf_metric1' in import filter from OSPF at the discussed router (one with BGP). -- 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)
-
Adam Priestley -
Ondrej Zajicek