2 upstreams 1 downstream BGP configuration optimization

[Job Snijders]

Hi Kevin,

Yes, this is normal. The routes are being rejected by the filter part that
prevents sending upstream routes from one upstream to another. Your bird
instance is aware of hundreds of thousands of paths to prefixes (routes),
but only 6 of them managed to pass your filter and be exported to your
upstream.

$ birdc show route export UPSTREAM1 all

The above command will show you what you announce to your upstream and all
details about each route such as the communities.

Kind regards,

Job

On Wed, Jun 5, 2019 at 16:54 Kevin B <test at teslahost.net> wrote:

> Thank you Job and Toke.
>
> I have tried the approach of marking import routes as large bgp
> communities, can you please tell me whether it's normal that bird is
> still trying to export numerous routes to my upstreams?
>
> I did 'birdc restart [proto]' of both upstreams and this is what I get
> in 'rejected' columns:
>
> UPSTREAM1:
>
>    Routes:         774396 imported, 6 exported, 774396 preferred
>    Route change stats:     received   rejected   filtered ignored
> accepted
>      Import updates:         777192          0          0 0     777192
>      Import withdraws:          253          0        --- 0        253
>      Export updates:        2320122    1551565     768545 ---         12
>      Export withdraws:          259        ---        --- ---     783957
>
> UPSTREAM2:
>
>    Routes:         758555 imported, 6 exported, 9573 preferred
>    Route change stats:     received   rejected   filtered ignored
> accepted
>      Import updates:        1039201          0          0 4    1039197
>      Import withdraws:        48501          0        --- 22      48479
>      Export updates:        4140531     808064    3332455 ---         12
>      Export withdraws:        41861        ---        --- ---    1567606
>
> DOWNSTREAM1:
>
>    Route change stats:     received   rejected   filtered ignored
> accepted
>      Import updates:             22          0          0 1         21
>      Import withdraws:       783868          0        --- 783864          4
>      Export updates:       10916109         28          0 ---   10916081
>      Export withdraws:       710987        ---        --- ---     710999
>
> On 6/4/19 3:14 PM, Job Snijders wrote:
> > Dear Kevin,
> >
> > On Tue, Jun 04, 2019 at 03:00:53PM +0000, Kevin B wrote:
> >> I have 2 upstream transit providers and 1 downstream customer we provide
> >> transit to - http://paste.debian.net/1086030/ (full Bird configuration
> with
> >> explanation)
> >>
> >> There is a problem: Bird is exporting all the imported prefixes from
> >> my upstreams back to them. For example 10.40.40.0/24 is being exported
> >> from us even when AS20's customer doesn't announce it, because it is
> >> announced somewhere else in the full table and we just export it back
> >> from the full view.
> >>
> >> Here is `birdc show protocols all` output -
> http://paste.debian.net/1086033/
> >>
> >> I would like to prevent exporting the full view tables imported from
> >> my upstreams back to them, can you help me to understand what is wrong
> >> with the configuration and why does it happen?
> > You'll have to mark the routes you receive on 'import', and act on those
> > markers on 'export'.
> >
> > I've spoken a bit about how to make robust routing policies, I hope this
> > is of use to you:
> >
> >
> https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4
> >
> >
> https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf
> >
> > Specifically in your example, I've added the use of BGP Large
> > Communities to help arrange what announcements go where, please compare
> > this untested example with your own deployment:
> http://paste.debian.net/1086041/
> >
> > Kind regards,
> >
> > Job
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190605/9238c30b/attachment.htm>