[c-nsp] IOS XR / advertise best-external
Adam Vitkovsky
Adam.Vitkovsky at gamma.co.uk
Mon May 18 03:26:33 EDT 2015
Hi Gert,
Wow that's something new.
You should get that only when "maximum-paths eibgp unequal-cost" is configured on the remote PEs and I'm pretty certain it's not on by default and you'd see different flags for that in fib and rib.
Wondering what is the trigger for this bug.
As Marian said and I heard that from other folks as well it seems indeed that the installation of additional (to be backup) prefixes and BGP PIC is on by default in this case (PE-CE Node protection) (I guess it's since 4.3.4 right?).
Though in my cases I've always used also the "local-repair/PE-CE link protection" functionality on all PEs in the AS so I had to use the below config anyways because IIRC without the below, on the primary PE I would not see the backup routes (marked as "b" in bgp table and installed in FIB as backups) pointing to the alternate PE (PE advertising the best external path):
address-family xxx
additional-paths selection route-policy xxxx
route-policy xxxx
set path-selection backup 1 install
end-policy
Since I had the above enabled on all PE routers I'm not sure if the above config affects only the PE-CE_link_protection feature or also the "automatic" PE-CE_node_protection feature.
But other folks confirmed already that they saw the correct behaviour (I assume without the above policy in place).
adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Gert Doering
> Sent: 17 May 2015 12:49
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] IOS XR / advertise best-external
>
> 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
---------------------------------------------------------------------------------------
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
More information about the cisco-nsp
mailing list