[c-nsp] IOS XR / advertise best-external
Arie Vayner
ariev at vayner.net
Sun May 17 16:19:15 EDT 2015
Gert,
The best-external feature is needed to get a backup path through the 2nd PE
for a dual attached CE site... This is used by PIC edge...
If you have an active/standby design, where a PE has the backup link, it
would be configured to prefer the remote PE's iBGP route (the remote PE
hosts the primary link).
Still, we want the primary PE to learn about the alternate path from the
backup PE.
This feature allows the backup PE to advertise the eBGP route even though
it is not selected as the best path.
HTH,Arie
On May 17, 2015 04:49, "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/
>
More information about the cisco-nsp
mailing list