[j-nsp] BGP multipath bug?

[Kevin Day]

I think I've found a bug dealing with multipath BGP routes. If a  
prefix has several routes with the same localpref/metric, they ALL  
have to perfectly match for any of them to get joined in a multipath  
next-hop. For example:


10.5.54.0/23       *[BGP/170] 1d 19:18:04, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                     [BGP/170] 1d 19:20:20, MED 100, localpref 25
                       AS path: 65001 3549 701 12163 I
                     > to 10.1.111.21 via ae2.106
                     [BGP/170] 1d 19:18:18, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.38 via ge-3/0/0.0

#1 and #3 in there are identical. They should be joined for a multihop  
route, but aren't. #2 is blocking it somehow. If I change the  
localpref so that 1 and 3 aren't the same as 2, it works:

10.5.54.0/23       *[BGP/170] 1d 19:36:35, MED 100, localpref 100,  
from 10.0.111.38
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                       to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 1d 19:36:21, MED 100, localpref 100
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                     [BGP/170] 1d 19:38:37, MED 100, localpref 25
                       AS path: 65001 3549 701 12163 I
                     > to 10.1.111.21 via ae2.106

Or, if I set all 3 back to 25, and shutdown the session to 65001 they  
link up:

10.5.54.0/23       *[BGP/170] 1d 19:36:35, MED 100, localpref 25, from  
10.0.111.38
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                       to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 1d 19:36:21, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0

Then when 65001 comes back up it gets even weirder:

10.5.54.0/23       *[BGP/170] 1d 19:51:41, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 1d 19:51:27, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                       to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 00:00:43, MED 100, localpref 25
                       AS path: 65001 3549 701 12163 I
                     > to 10.1.111.21 via ae2.106

Now it's created the multihop next-hop, but isn't selecting it  
(inactive reason: router id), but it isn't using the route learned  
from 65001 either. So, just reintroducing an unselected route from  
another peer is changing things again.

Even depref'ing 65001's route again doesn't clear this:

10.5.54.0/23       *[BGP/170] 1d 20:00:23, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 1d 20:00:09, MED 100, localpref 25
                       AS path: 65000 209 701 12163 I
                     > to 10.0.111.34 via ge-2/2/0.0
                       to 10.0.111.38 via ge-3/0/0.0
                     [BGP/170] 00:00:51, MED 100, localpref 24
                       AS path: 65001 3549 701 12163 I
                     > to 10.1.111.21 via ae2.106



What am I doing wrong here? :) Is there any way to apply an import  
policy to the multipath route that's different from the non-multihop  
route, so I can force it to be preferred?

-- Kevin