[c-nsp] IOS XR / advertise best-external
Dan Peachey
dan at illusionnetworks.com
Sun May 17 15:40:08 EDT 2015
On 17 May 2015 12:50 pm, "Gert Doering" <gert at greenie.muc.de> 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
gert at greenie.muc.de
> fax: +49-89-35655025
gert at net.informatik.tu-muenchen.de
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> 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
More information about the cisco-nsp
mailing list