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
