[Cisco-asr9k-ug] Unexpected multipath changes after 6.2.X

[Aaron Weintraub]

Hi guys:

We ran into an issue that we eventually backtraced to CSCvf76253 after
upgrading from 5.3.4 to 6.3.1 (needed for 9906 deployment).

Short version:

When a RR server reflects out a route that it is using iBGP multipath for
the best paths, it does next-hop-self before sending it to the other full
mesh peers.  We did see routing loops as a result of this behavior.

Commentary:

RFC 4456, section 10:

   In addition, when a RR reflects a route, it SHOULD NOT modify the
   following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
   Their modification could potentially result in routing loops.

I unfortunately don't have the the bug ID of the feature request that let to
a code change that led to this side effect.  Our SE was able to find it, I
think it was maybe only expected to be implemented for VRFs or other such
things, but I'm sure the fine cisco folk can find it.

More commentary:

Cisco suggests using 'next-hop-unchanged multipath' as a workaround. 
However, this command operates on BOTH eBGP and iBGP multipath.  There is
currently no way to preserve the 5.3.4 "correct" behavior of eBGP multipath
next hop being rewritten but iBGP multipath NOT being rewritten.

Can anyone lean on anyone to find out exactly how this is going to be
resolved in 6.3.2 or via SMU?

-aw