I should set a lab as I cannot debug easily on prod devices.
Anyway PE1 after does advertise the route to EBGP peer even after the route is
back again in the external AS, here’s an excerpt of the advertised routes
Network Next Hop Metric LocPrf Weight Path
*>i 7.7.7.7/32 X.X.X.2 0 33 0 ?
The EBGP peer, which I do not control, for some reason discards the update that
it receives from PE1. As a matter of fact the loopback 7.7.7.7 is reachable
correctly across the external AS
Regarding PE1, I think it discards the update coming from the external AS: I
have no clue, afaik it should prefer EBGP information coming with LP=222).
Andrea
From: Pete Lumbis [mailto:[email protected]]
Sent: giovedì 23 ottobre 2014 19:14
To: Pasquino Andrea
Cc: [email protected]
Subject: Re: [c-nsp] IBGP route stays stuck
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]<mailto:[email protected]>> wrote:
Pete,
here you are steady state: dummy route 7.7.7.7/32<http://7.7.7.7/32> comes from
EBGP
PE1:
Network Next Hop Metric LocPrf Weight Path
*> 7.7.7.7/32<http://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<http://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<http://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<http://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]<mailto:[email protected]>]
Sent: giovedì 23 ottobre 2014 17:15
To: Pasquino Andrea
Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>]
Sent: mercoledì 22 ottobre 2014 15:44
To: Pasquino Andrea
Cc: [email protected]<mailto:[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]><mailto:[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]><mailto:[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]<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/
