Maybe the PE1 eBGP peer is also preferring the route via PE2, so the announcement to PE1 contains it's own AS Number?
On Thu, Oct 23, 2014 at 11:47 AM, Pasquino Andrea <[email protected]> wrote: > Pete, > > here you are steady state: dummy route 7.7.7.7/32 comes from EBGP > > PE1: > Network Next Hop Metric LocPrf Weight Path > *> 7.7.7.7/32 X.X.X.93 222 0 XXX9 XXX7 > 65000 ? > PE2: > Network Next Hop Metric LocPrf Weight Path > *>i 7.7.7.7/32 X.X.X.8 0 222 0 XXX9 XXX7 > 65000 ? > > > ip route vrf xxxx 7.7.7.7 255.255.255.255 Dialer319 172.19.9.2 240 > ! > router bgp XXXX > ! > address-family ipv4 vrf xxxx > redistribute static route-map TER > ! > route-map TER permit 10 > set local-preference 33 > set weight 0 > > +++++++++++++++++++++++++++++++++++++++++++++ > > Now I stop announcing the route from EBGP, the floating static kicks in: > > PE1: > PSMDCI11ME1#sh ip bgp vpnv4 vrf sumitomo > *>i 7.7.7.7/32 X.X.X.2 0 33 0 ? > PE2: > Network Next Hop Metric LocPrf Weight Path > *> 7.7.7.7/32 X.X.X.2 0 33 0 ? > > +++++++++++++++++++++++++++++++++++++++++++++ > > When I restart announcing the route from EBGP nothing changes... > I have to delete the static route on PE2 and putting it back again. > > Andrea > > > From: Pete Lumbis [mailto:[email protected]] > Sent: giovedì 23 ottobre 2014 17:15 > To: Pasquino Andrea > Cc: [email protected] > Subject: Re: [c-nsp] IBGP route stays stuck > > Do you happen to have the output of the BGP tables (specifically the > a.b.c.d route) from PE1 and PE2 during the failure? My guess is that it's > "expected" (in the sense BGP is doing what it's supposed to, even if > undesired) and seeing it in the broken state should make it easy to reverse > engineer why it happens. > > -Pete > > On Thu, Oct 23, 2014 at 9:59 AM, Pasquino Andrea <[email protected]> > wrote: > Pete, > > Actually the floating static on PE2 is redistributed with weight 0 by > default. > I have configured on PE2 a route-map in order to redistribute into BGP the > routes coming from MPBGP with a higher weight, no luck. I think I’m going > to check with TAC… > > Andrea > > From: Pete Lumbis [mailto:[email protected]] > Sent: mercoledì 22 ottobre 2014 15:44 > To: Pasquino Andrea > Cc: [email protected] > Subject: Re: [c-nsp] IBGP route stays stuck > > Perhaps when the floating static kicks in on PE2 the weight will be 32768, > most likely making it the best route in the BGP table, causing it to > advertise to PE1? I've seen similar configurations run into this. If this > is your issue the solution is a route-map on the redistribution statement > setting the weight to 0 > > On Wed, Oct 22, 2014 at 2:30 AM, Pasquino Andrea <[email protected] > <mailto:[email protected]>> wrote: > Hello, > > This is the scenario: > > I have PE1 and PE2 in AS100 > PE1 has an EBGP peering with AS200 and receives a certain prefix a.b.c.d > with LP=222 > The same prefix a.b.c.d is redistributed on PE2 with LP=33 from a floating > static route, and serves as a back-up route > > Now here's what happens: if for some reason AS200 stops announcing prefix > a.b.c.d, then the announcement from PE2 kicks and we are happy (back-up > runs fine) > > When AS200 starts again announcing prefix a.b.c.d, then the announcement > from PE2 does not get flushed from PE1 and PE2. We have to erase the "ip > route vrf blahblah" command and rewrite it > > Have you any clues ? > > Andrea > > _______________________________________________ > 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/
