On 14.12.2012, at 02:42, Jason Lixfeld <ja...@lixfeld.ca> wrote: > So after thinking about this a little more, I realized that my ME3600 example > was incorrect. The reference device wasn't actually sitting equidistant > between the two PEs sourcing the default routes. When I check the routing > table and the cef table for the default route, the results lead me to believe > that multi-path is actually working, meaning that add path is doing what it's > supposed to. Am I wrong? > > rrc-3600#sh ip bgp vpnv4 vrf Inetv4 0.0.0.0/0 > BGP routing table entry for 1:4:0.0.0.0/0, version 347497 > Paths: (2 available, best #2, table Inetv4, not advertised to EBGP peer) > Multipath: iBGP > Not advertised to any peer > Local > 1.1.1.11 (metric 50) from 1.1.1.11 (1.1.1.11) > Origin IGP, metric 0, localpref 100, valid, internal, multipath > Community: 1:65535 no-export > Extended Community: RT:1:4 > mpls labels in/out nolabel/16000 > Local > 1.1.1.10 (metric 50) from 1.1.1.10 (1.1.1.10) > Origin IGP, metric 0, localpref 100, valid, internal, multipath, best > Community: 1:65535 no-export > Extended Community: RT:1:4 > mpls labels in/out nolabel/289985 > rrc-3600#sh ip cef vrf Inetv4 0.0.0.0/0 detail > 0.0.0.0/0, epoch 0, flags rib defined all labels, per-destination sharing > recursive via 1.1.1.10 label 289985 > nexthop 72.15.51.42 TenGigabitEthernet0/1 label 100 > recursive via 1.1.1.11 label 16000 > nexthop 72.15.51.87 TenGigabitEthernet0/2 label 94 > rrc-3600#
No, it's working because the defaults-with-different-NHs are coming from different peers/RRs. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/