<div><div style="color:rgb(49,49,49);word-spacing:1px" dir="auto"><div dir="auto" style="font-size:1rem">Hi Kevin,</div><div dir="auto"><br></div><div dir="auto" style="font-size:1rem">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.</div></div><div dir="auto" style="color:rgb(49,49,49);word-spacing:1px"><br></div><div dir="auto" style="font-size:1rem;color:rgb(49,49,49);word-spacing:1px">$ birdc show route export UPSTREAM1 all</div><div dir="auto" style="color:rgb(49,49,49);word-spacing:1px"><br></div><div dir="auto" style="font-size:1rem;color:rgb(49,49,49);word-spacing:1px">The above command will show you what you announce to your upstream and all details about each route such as the communities.</div><div dir="auto" style="color:rgb(49,49,49);word-spacing:1px"><br></div><div dir="auto" style="font-size:1rem;color:rgb(49,49,49);word-spacing:1px">Kind regards,</div><div dir="auto" style="color:rgb(49,49,49);word-spacing:1px"><br></div><div dir="auto" style="font-size:1rem;color:rgb(49,49,49);word-spacing:1px">Job</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2019 at 16:54 Kevin B <<a href="mailto:test@teslahost.net">test@teslahost.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you Job and Toke.<br>
<br>
I have tried the approach of marking import routes as large bgp <br>
communities, can you please tell me whether it's normal that bird is <br>
still trying to export numerous routes to my upstreams?<br>
<br>
I did 'birdc restart [proto]' of both upstreams and this is what I get <br>
in 'rejected' columns:<br>
<br>
UPSTREAM1:<br>
<br>
   Routes:         774396 imported, 6 exported, 774396 preferred<br>
   Route change stats:     received   rejected   filtered ignored   accepted<br>
     Import updates:         777192          0          0 0     777192<br>
     Import withdraws:          253          0        --- 0        253<br>
     Export updates:        2320122    1551565     768545 ---         12<br>
     Export withdraws:          259        ---        --- ---     783957<br>
<br>
UPSTREAM2:<br>
<br>
   Routes:         758555 imported, 6 exported, 9573 preferred<br>
   Route change stats:     received   rejected   filtered ignored   accepted<br>
     Import updates:        1039201          0          0 4    1039197<br>
     Import withdraws:        48501          0        --- 22      48479<br>
     Export updates:        4140531     808064    3332455 ---         12<br>
     Export withdraws:        41861        ---        --- ---    1567606<br>
<br>
DOWNSTREAM1:<br>
<br>
   Route change stats:     received   rejected   filtered ignored   accepted<br>
     Import updates:             22          0          0 1         21<br>
     Import withdraws:       783868          0        --- 783864          4<br>
     Export updates:       10916109         28          0 ---   10916081<br>
     Export withdraws:       710987        ---        --- ---     710999<br>
<br>
On 6/4/19 3:14 PM, Job Snijders wrote:<br>
> Dear Kevin,<br>
><br>
> On Tue, Jun 04, 2019 at 03:00:53PM +0000, Kevin B wrote:<br>
>> I have 2 upstream transit providers and 1 downstream customer we provide<br>
>> transit to - <a href="http://paste.debian.net/1086030/" rel="noreferrer" target="_blank">http://paste.debian.net/1086030/</a> (full Bird configuration with<br>
>> explanation)<br>
>><br>
>> There is a problem: Bird is exporting all the imported prefixes from<br>
>> my upstreams back to them. For example <a href="http://10.40.40.0/24" rel="noreferrer" target="_blank">10.40.40.0/24</a> is being exported<br>
>> from us even when AS20's customer doesn't announce it, because it is<br>
>> announced somewhere else in the full table and we just export it back<br>
>> from the full view.<br>
>><br>
>> Here is `birdc show protocols all` output - <a href="http://paste.debian.net/1086033/" rel="noreferrer" target="_blank">http://paste.debian.net/1086033/</a><br>
>><br>
>> I would like to prevent exporting the full view tables imported from<br>
>> my upstreams back to them, can you help me to understand what is wrong<br>
>> with the configuration and why does it happen?<br>
> You'll have to mark the routes you receive on 'import', and act on those<br>
> markers on 'export'.<br>
><br>
> I've spoken a bit about how to make robust routing policies, I hope this<br>
> is of use to you:<br>
><br>
>      <a href="https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4" rel="noreferrer" target="_blank">https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4</a><br>
><br>
>      <a href="https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf" rel="noreferrer" target="_blank">https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf</a><br>
><br>
> Specifically in your example, I've added the use of BGP Large<br>
> Communities to help arrange what announcements go where, please compare<br>
> this untested example with your own deployment: <a href="http://paste.debian.net/1086041/" rel="noreferrer" target="_blank">http://paste.debian.net/1086041/</a><br>
><br>
> Kind regards,<br>
><br>
> Job<br>
</blockquote></div></div>