[c-nsp] IOS XR / advertise best-external

[Gert Doering]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 291 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20150517/2e6e872d/attachment.sig>