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 g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpNxFv7BMzfr.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/