I would be careful using neighbor weight in this case. If anything, I would set the specific route in question's weight via route-map, unless your network is very simple (only this one uplink).
-Blake On Thu, Aug 29, 2013 at 10:08 AM, Chris Hunt <[email protected]> wrote: > Pete & Mike hit the nail on the head: "Routes learned through another > BGP peer have a default weight of 0 and routes sourced by the local > router have a default weight of 32768." I added a "neighbor weight" > line to my colo router and now it's working fine: > > address-family ipv4 vrf TestCo > redistribute connected > redistribute static > neighbor 10.180.3.2 remote-as 65000 > neighbor 10.180.3.2 update-source GigabitEthernet0/2.690 > neighbor 10.180.3.2 activate > neighbor 10.180.3.2 next-hop-self > neighbor 10.180.3.2 default-originate > neighbor 10.180.3.2 weight 33000 > no synchronization > exit-address-family > > Thanks very much for the help. May I be able to return the favor > > -Chris > > > On 8/28/2013 6:11 PM, Pete Lumbis wrote: > > Classic redistribution race condition. Notice in the failed state that > > the BGP table shows two routes, one from the ISP and one that is > > locally sourced ( from 0.0.0.0....weight 32768). > > > > What happens is that BGP is picking a best route and only presenting > > that single route up to the routing table. The routing table is now > > comparing the static against the best route BGP is presenting. Since > > the BGP presented route /is the static/, it fails. > > > > When you clear the PPPoE session the static is removed from the > > routing table. Because it's no longer in the routing table it's no > > longer a candidate for redistribution into BGP. BGP then runs best > > path and picks the ISP learned route, that goes in the routing table > > and the floating static is kept at bay. > > > > The easiest fix is to apply a route map to your "redistribute static" > > statement in BGP to either not redistribute the floating static or to > > make it less preferred than the ISP route. > > > > -Pete > > > > > > On Wed, Aug 28, 2013 at 6:38 PM, Chris Hunt <[email protected] > > <mailto:[email protected]>> wrote: > > > > Gurus, > > I'm having trouble getting BGP to preempt a floating static > route. > > The situation looks like this, I've got two paths from our colo to a > > network at remote site (4.4.4.0/24 <http://4.4.4.0/24> in this lab > > example): one metro > > ethernet and one DSL , both inside a vrf. We're running BGP over the > > metro ethernet circuit and just using a floating static in case the > > ethernet fails and BGP goes down. That seems to work OK: > > router-1#show ip route vrf TestCo 4.4.4.0 > > Routing entry for 4.4.4.0/24 <http://4.4.4.0/24> > > Known via "bgp 65517", distance 20, metric 0 > > Tag 65000, type external > > Last update from 10.180.3.2 00:00:01 ago > > Routing Descriptor Blocks: > > * 10.180.3.2, from 10.180.3.2, 00:00:01 ago > > Route metric is 0, traffic share count is 1 > > AS Hops 1 > > Route tag 65000 > > > > > > When the ethernet fails, the BGP adjacency goes down the floating > > static > > pops up in the FIB: > > Routing entry for 4.4.4.0/24 <http://4.4.4.0/24> > > Known via "static", distance 254, metric 0 > > Redistributing via bgp 65517 > > Advertised by bgp 65517 > > Routing Descriptor Blocks: > > * 192.168.100.14 > > Route metric is 0, traffic share count is 1 > > > > > > Then when I bring up the Ethernet link, BGP establishes, and the colo > > router receives the advertisement: > > router-1#show ip bgp vpnv4 vrf TestCo neighbors 10.180.3.2 routes > > BGP table version is 392820, local router ID is 172.16.0.241 > > Status codes: s suppressed, d damped, h history, * valid, > best, i - > > internal, > > r RIB-failure, S Stale > > Origin codes: i - IGP, e - EGP, ? - incomplete > > > > Network Next Hop Metric LocPrf Weight Path > > Route Distinguisher: 200:1 (default for vrf TestCo) > > * 4.4.4.0/24 <http://4.4.4.0/24> 10.180.3.2 0 > > 0 65000 i > > > > Total number of prefixes 1 > > > > router-1#show ip bgp vpnv4 vrf TestCo 4.4.4.0 > > BGP routing table entry for 200:1:4.4.4.0/24 <http://4.4.4.0/24>, > > version 392815 > > Paths: (2 available, best #2, table TestCo) > > Advertised to update-groups: > > 4 6 > > 65000 > > 10.180.3.2 from 10.180.3.2 (10.180.3.2) > > Origin IGP, metric 0, localpref 100, valid, external > > Extended Community: RT:200:1 > > mpls labels in/out 376/nolabel > > Local > > 192.168.100.14 from 0.0.0.0 (x.x.x.241) > > Origin incomplete, metric 0, localpref 100, weight 32768, > valid, > > sourced, best > > Extended Community: RT:200:1 > > mpls labels in/out 376/nolabel > > > > > > > > But it does not pre-empt the floating static in the FIB: > > router-1#show ip ro vrf TestCo 4.4.4.0 > > Routing entry for 4.4.4.0/24 <http://4.4.4.0/24> > > Known via "static", distance 254, metric 0 > > Redistributing via bgp 65517 > > Advertised by bgp 65517 > > Routing Descriptor Blocks: > > * 192.168.100.14 > > Route metric is 0, traffic share count is 1 > > > > > > If i then clear the PPPoE session, the BGP route pops into the FIB > and > > we start all over: > > router-1#show ip route vrf TestCo 4.4.4.0 > > Routing entry for 4.4.4.0/24 <http://4.4.4.0/24> > > Known via "bgp 65517", distance 20, metric 0 > > Tag 65000, type external > > Last update from 10.180.3.2 00:00:01 ago > > Routing Descriptor Blocks: > > * 10.180.3.2, from 10.180.3.2, 00:00:01 ago > > Route metric is 0, traffic share count is 1 > > AS Hops 1 > > Route tag 65000 > > > > > > Any ideas what I'm doing wrong? Here's the config for the remote > > office: > > router bgp 65000 > > no synchronization > > bgp router-id 10.180.3.2 > > bgp log-neighbor-changes > > network 4.4.4.0 mask 255.255.255.0 > > neighbor 10.180.3.1 remote-as 65517 > > neighbor 10.180.3.1 update-source GigabitEthernet0/0 > > no auto-summary > > > > And the colo config (7206VXR): > > address-family ipv4 vrf TestCo > > redistribute connected > > redistribute static > > neighbor 10.180.3.2 remote-as 65000 > > neighbor 10.180.3.2 update-source GigabitEthernet0/2.690 > > neighbor 10.180.3.2 activate > > neighbor 10.180.3.2 next-hop-self > > neighbor 10.180.3.2 default-originate > > no synchronization > > exit-address-family > > > > > > > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > <mailto:[email protected]> > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
