On 17 May 2015 12:50 pm, "Gert Doering" <[email protected]> wrote: > > Hiya, > > looking for some explanation or a pointer to documentation. > > I thought I knew what "bgp advertise best-external" would do, namely: > if BGP has multiple paths and the standard BGP best path is internal, > find out what *would* be the best path if no iBGP path exists, and > announce that to all iBGP neighbours. Benefit: if the iBGP path goes > away (due to withdraw on the other end), the remote neighbour has an > alternative available right away, and doesn't have to do a "withdraw > on iBGP -> announce external best path on iBGP" cycle first. > > So, this sounds like something one would want, always, if the extra > CPU and memory consumption on the other end are acceptable. > > > Now... in practice, this seems to lead to installation of the external > best-path in the RIB and FIB, leading to load-sharing between iBGP best > path and eBGP best-path, which I find totally surprising, and totally > unwanted behaviour... (it actually caused quite a bit of issue with > packet distribution to internal services, as it does not respect the > BGP decision anymore, but load-balances between primary and secondary > node...) > > IOS XR 4.3.4SP6 on ASR9001. > > With "address-family ipv4 unicast advertise best-external", I see this > (addresses of BGP peers and next-hops changed, but consistently so): > > RP/0/RSP0/CPU0:Cisco-F-X#sh ip b 194.97.129.1/32 > Sat May 16 23:23:00.986 MEDST > BGP routing table entry for 194.97.129.1/32 > Versions: > Process bRIB/RIB SendTblVer > Speaker 87622173 87622173 > Last Modified: May 9 14:43:16.138 for 1w0d > Paths: (3 available, best #2, not advertised to EBGP peer) > > [ Path #1 removed, as it's totally uninteresting here ] > > Path #2: Received by speaker 0 > 65300 > 10.10.11.45 (metric 5642752) from 10.10.11.15 (10.20.20.74) > Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, import suspect > Received Path ID 0, Local Path ID 1, version 87622173 > Community: 5539:414 5539:499 no-export > > [ this is the iBGP best path ] > > Path #3: Received by speaker 0 > Advertised to update-groups (with more than one peer): > 0.14 > 65300 65300 65300 > 10.10.11.241 from 10.10.11.241 (194.97.129.1) > Origin IGP, metric 10000, localpref 100, valid, external, best-external, import suspect > Received Path ID 0, Local Path ID 5, version 87622159 > Community: 5539:434 5539:499 no-export > Origin-AS validity: not-found > > [ this is the eBGP "best-external" path - it's sort of internal still, > as this is an internal node - but technically it's eBGP, and BGP does > the right thing regarding best path, best-external, and "who is this > advertised to ] > > > Now, *this* is *not* what I would expect to see as consequence... > > RP/0/RSP0/CPU0:Cisco-F-X#sh ip route 194.97.129.1 > Sat May 16 23:23:54.989 MEDST > > Routing entry for 194.97.129.1/32 > Known via "bgp 5539", distance 200, metric 0 > Tag 65300 > Number of pic paths 1 , type internal and external > Installed May 9 14:43:16.614 for 1w0d > Routing Descriptor Blocks > 10.10.11.45, from 10.10.11.15 > Route metric is 0 > 10.10.11.241, from 10.10.11.241, BGP best-external, BGP external > Route metric is 10000 > No advertising protos. > > RP/0/RSP0/CPU0:Cisco-F-X#sh cef 194.97.129.1 > Sat May 16 23:26:20.777 MEDST > 194.97.129.1/32, version 76418887, internal 0x14000001 (ptr 0xa1045a14) [1], 0x0 (0x0), 0x0 (0x0) > Updated May 9 14:43:16.617 > Prefix Len 32, traffic index 0, precedence n/a, priority 4 > BGP Attribute: id: 0xc4eb, Local id: 0xbc96, Origin AS: 65300, Next Hop AS: 65300 > > via 10.10.11.45, 5 dependencies, recursive [flags 0x6000] > path-idx 0 [0x9eac8c88 0x0] > next hop 10.10.11.45 via 10.10.11.45/32 > via 10.10.11.241, 5 dependencies, recursive, bgp-ext, bgp-best-ext [flags 0x6060] > path-idx 1 [0x9e5a92c0 0x0] > next hop 10.10.11.241 via 10.10.11.241/32 > > > ... and indeed, it nicely load-shares packets between the primary service > instance (behind 10.10.11.45) and the secondary service instance > (on the base IP 10.10.11.241). > > > Removing "address-family ipv4 unicast best-external" leads to this... > > RP/0/RSP0/CPU0:Cisco-F-X#sh ip route 194.97.129.1 > Sat May 16 23:32:56.028 MEDST > > Routing entry for 194.97.129.1/32 > Known via "bgp 5539", distance 200, metric 0 > Tag 65300, type internal > Installed May 16 23:30:11.979 for 00:02:44 > Routing Descriptor Blocks > 10.10.11.45, from 10.10.11.15 > Route metric is 0 > No advertising protos. > > ... and the issues we've experienced are gone. > > > The example above is for one of our DNS instances (where the issue > manifested), but I have checked other prefixes as well - and, for example, > for a BGP customer with "local-pref 500", the box happily load-balanced > the packets "one internal, towards the customer, and one external, to one > of our eBGP peers, on the back up path towards the customer". > > This does not make sense... so... basically what am I overlooking? > > (Slapping me with documentation is fine, explaining under which circumstances > this behaviour makes sense and/or how best-external can be used with this > behaviour would be even better :-) ) > > thanks, > > gert > > -- > USENET is *not* the non-clickable part of WWW! > // www.muc.de/~gert/ > Gert Doering - Munich, Germany [email protected] > fax: +49-89-35655025 [email protected] > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/
Hi Gert, I have used this in the past on ASR9001 which was running 4.3.4 SP1 IIRC. Unfortunately I don't have access to this network anymore to double check but I'm pretty certain this is not the behaviour I observed. The best-external path should be seen as an additional path in the BGP table but not be installed in the RIB/FIB as far as I understand. I assume there is nothing else in your BGP config which might be causing this? No 'additional-paths' or 'maximum-paths' commands for example? Regards, Dan _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
