So in today's case, I went into the Cisco BGP process and did a "neighbor
x.x.x.x shutdown"
>From there the OpenBSD route-reflector removed the routes from those
neighbors from the rib.
The other OpenBSD route-reflector clients however kept those routes around.
This was first noticed on Friday, when I changed peering interfaces on
PE-CE, which re-ran LDP against the OSPF routes,
but those routes never made it back to my PE in the Datacenter, and the
Customer's network was down while
I troubleshooted. I think I need to do some more testing and data gathering
and perhaps send a bug report
if my configs look good there. I would just think that if the PE withdrew
the route from the route-reflector, that
the reflector clients would remove the routes as well...

On Mon, Apr 8, 2019 at 5:29 PM Tom Smyth <tom.sm...@wirelessconnect.eu>
wrote:

> Hi Henry,
>
> How long are you leaving the sessions down for  on the PE router ?
> are you leaving the sessions down past the hold time value on the neigbour
> of the router that you are shutting down.
> are you doing a graceful shutdown?
> or are you simply rebooting the neigbour
> if im not mistaken  I dont think the neighbour would withdraw the
> routes until the
> hold time has expired ...
> im subject to correction on this one... but it is the behaviour I have
> empirically observed
> on the bgp routers that i manage
> I hope this helps
> Tom Smyth
>
>
>
>
>
> On Mon, 8 Apr 2019 at 22:11, Henry Bonath <he...@thebonaths.com> wrote:
> >
> > Hello, I am seeing some BGP VPNv4 routes staying populated in
> > the RIB of route-reflector clients even after dropping the originating
> neighbor.
> >
> > I'm on OpenBSD 6.4, running MPLS L3VPN.
> >
> > I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> > I run OSPF to distribute Loopbacks into an Area (100)
> > We run Cisco devices for our Provider Edge installed on site at
> > Customer Premise.
> > All MPLS PE devices neighbor with both route reflectors.
> >
> > My bgpd.conf from the route reflectors:
> > ===================================================
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 172.16.16.212
> > nexthop qualify via default
> >
> > group "IBGP" {
> >         remote-as $ASN
> >         announce IPv4 vpn
> >         route-reflector 172.16.16.212
> >         local-address 172.16.16.212
> >         neighbor 100.92.64.0/18 {
> >         }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> > ===================================================
> >
> > bgpd.conf from an OpenBSD PE:
> > ===================================================
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 100.92.127.121
> >
> > rdomain 2 {
> >         rd 64670:37
> >         import-target rt 64670:37
> >         export-target rt 64670:37
> >         # advertise summary of tenant Subnet:
> >         network 172.29.21.0/24
> >
> >         # Redistribute from OSPF (Priority 32)
> >         network inet priority 32
> >         depend on mpe1
> > }
> >
> > group "IBGP" {
> >         remote-as $ASN
> >         announce IPv4 vpn
> >         set rtlabel FROM_BGP
> >         local-address 100.92.127.121
> >         neighbor 172.16.16.211 {
> >                 descr "bgp-rr-01"
> >         }
> >         neighbor 172.16.16.212 {
> >                 descr "bgp-rr-02"
> >         }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from ibgp
> > allow to ibgp
> >
> > ===================================================
> >
> > The problem comes if I shutdown one of my Premise equipment PE
> > devices, or an OpenBSD PE,
> > on the other OpenBSD PEs that remain up, they still show the routes
> > that were advertised by the
> > now shutdown device.
> >
> > If I log into a route reflector and run a "bgpctl show rib" those
> > routes are no longer there as i expected,
> > though they persist at the OpenBSD reflector clients.
> >
> > Example output after shutting down the 100.92.127.21 Cisco PE observed
> > from the OpenBSD PE
> > that is listening to 64670:37 rt/rd:
> >
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >        S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination          gateway          lpref   med aspath origin
> > I*>     N rd 64670:37 192.168.11.0/24 100.92.127.21      100     2 ?
> > I*      N rd 64670:37 192.168.11.0/24 100.92.127.21      100     2 ?
> > I*>     N rd 64670:37 192.168.15.0/24 100.92.127.21      100     2 ?
> > I*      N rd 64670:37 192.168.15.0/24 100.92.127.21      100     2 ?
> > I*>     N rd 64670:37 192.168.20.0/24 100.92.127.21      100     3 ?
> > I*      N rd 64670:37 192.168.20.0/24 100.92.127.21      100     3 ?
> > I*>     N rd 64670:37 192.168.100.0/24 100.92.127.21      100     2 ?
> > I*      N rd 64670:37 192.168.100.0/24 100.92.127.21      100     2 ?
> > I*>     N rd 64670:37 192.168.110.0/24 100.92.127.21      100     3 ?
> > I*      N rd 64670:37 192.168.110.0/24 100.92.127.21      100     3 ?
> > I*>     N rd 64670:37 192.168.150.0/24 100.92.127.21      100     2 ?
> > I*      N rd 64670:37 192.168.150.0/24 100.92.127.21      100     2 ?
> > I*>     N rd 64670:37 192.168.200.0/24 100.92.127.21      100     2 ?
> > I*      N rd 64670:37 192.168.200.0/24 100.92.127.21      100     2 ?
> >
> > Shouldn't those routes disappear once the 100.92.127.21 router is
> shutdown?
> >
> > Thanks for any help you all  have to offer!
> > -Henry
> >
>
>
> --
> Kindest regards,
> Tom Smyth
>
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.
>

Reply via email to