BGP prefix filter list

Thu May 16 11:24:46 UTC 2019

Hi Baldur,

Have you tried disabling storage of received updates from your upstream on
your edge/PE or Border? Just remove *soft-reconfiguration inbound* for eBGP
peering with your upstream/s. This will resolve your issue.

If you have multiple links to different upstream providers and you want to
simplify your network operation, you might want to introduce a pair of
route reflectors to handle all your IP and MPLS VPN routes...

Cheers,
Ahad

On Thu, May 16, 2019 at 4:24 AM Baldur Norddahl <baldur.norddahl at gmail.com>
wrote:

> Hello
>
> On Wed, May 15, 2019 at 3:56 PM Mike Hammett <nanog at ics-il.net> wrote:
>
>> What is the most common platform people are using with such limitations?
>> How long ago was it deprecated?
>>
>>
>>
> We are a small network with approx 10k customers and two core routers. The
> routers are advertised as 2 million FIB and 10 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190516/3eab6dc2/attachment.html>