Re: Limit of numbers of BGP communities
> On 12 Jul 2024, at 14:57, Douglas Fischer wrote: > > Unfortunately, this number of 100 BGP communities has no basis, at least not > yet, in the RFC. A RFC is just a Request For Comments documents comments have been given amongst that in the form of the NLNOG BGP Filter Rules and other operators have also voiced their opinions, each network is their own. There is also no BCP (Best Current Practice) document on this subject; nor a STD (Standard). Operators can fortunately decide what they accept or not, own network, own rules, bit the point of an Autonomous System. > It is just a recommendation (a very healthy one, by the way) from the NLNOG > team. > > As far as I remember, neither the maximum mask limit of /24 for IPv4 nor /48 > for IPv6 in a BGP session are defined in RFC as either must or should. > > It would be good if it were in the RFCs, but it is not. In a way, all the NLNOG BGP Filter Rules are effectively a BCP, it is just not a document that went through the IETF process. As it is a changing target, unlikely that a IETF BCP makes sense either IMHO. Greets, Jeroen
Re: Limit of numbers of BGP communities
> On 12 Jul 2024, at 04:30, Ponikierski, Grzegorz via Bird-users > wrote: > > Hello all! > How many standard communities, extended communities and large communities, > user can apply on a route using Bird? BGP UPDATE message has finite size so I > guess that there must be a limit somewhere. The limit is that ISPs are limiting it to a 100: https://bgpfilterguide.nlnog.net/guides/many_communities/ Above that, it will be emptied completely in many networks. Greets, Jeroen
Re: Failover BGP servers?
> On 29 Mar 2024, at 10:48, Yasen Atanasov wrote: > > Hello, > Lets imagine I have 2 BGP servers announcing same subnet. BGP sessions with > upstream are in different VLAN. Both servers have keepalived and all clients > are using for default route the virtual address. The idea is if I need to > upgrade/rebuild one of the servers the clients will still have connectivity > trough the other server. Do I need to do something special in the bird config > or just announcing the same net is enough? Just announce the same net and ensure you do not have 'state': connection tracking... otherwise you need to do connection tracking state handover and things become nasty very quick. Also, in keepalived or as a manual trigger have a script that removes the announce for the prefix the moment it detects it does not have proper connectivity. One choice there is then also if only the primary does announce for incoming traffic or not, traffic load balancing can be a good thing, but might not work unless your upstream does ECMP for you. As you note VLAN, ensure that that VLAN has 2 different physical underlying paths, otherwise you will lose connectivity anyway if a single link that underlies it dies. If it is really a single link, one does not really need separate VLANs btw, 1 remote router, 2 IPs for your side is then enough. A separate VLAN can be nice to cleanly separate though. BFD and low timers also come to mind too if you really want to do 'failover' and not 'I know it is going down soon, lets stop announces for the prefix from the router I am going to play with'. Greets, Jeroen
Re: Q: rpki feed failure
> On 29 Feb 2024, at 09:48, Elmar K. Bins via Bird-users > wrote: > > Hi friends, > > a probably simple question that I haven't found any documentation about, so... > > We're using Cloudflare's RPKI cache from our BIRD instances, but since > yesterday I'm getting an error info in `show protocols`: > > rpki1 RPKI ---up 15:33:17.594 > Cache-Error-No-Data-Available > > What does the error message mean? Does the remote side not have data > available, > or is this about some local issue? Checking the code: https://gitlab.nic.cz/labs/bird/-/blob/master/proto/rpki/rpki.c#L279 Seems like it. > I'd like to clear this up before I ask Cloudflare... Instead heavily suggest running 2 stayrtr instances yourself. What if you lose connectivity to the outside world? For AS5 I generate IRR data rpki-client and rsync rpki-client.json every 10 minutes to my 2 stayrtr instances. If the rpki-client hosts goes down, then they do not update the rpki-client.json as there is no new one, but stayrtr stays up and running. If I upgrade stayrtr, there is always the second one up and running. Scale to more nodes for more resiliency :). On top I run another set of stayrtr instances for IRR data, need to write that down still how that setup now finally works. Greets, Jeroen
Re: Defines for mixed IPv6/IPv4
> On 25 Jan 2024, at 09:23, Maria Matejka wrote:
>
>
>
> On 25 January 2024 08:34:36 CET, Jeroen Massar wrote:
>>
>>
>>> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>>>
>>>
>>>
>>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
>>> wrote:
>>>>
>>>>
>>>>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
>>>>> wrote:
>>>>>
>>>>>
>>>>> Hello bird users,
>>>>>
>>>>> I am wondering how you handle matching both IPv6 and IPv4 prefixes
>>>>> efficiently.
>>>>>
>>>>> We have tons of blocks in our config like these:
>>>>
>>>> Generate the configs.
>>>
>>> Not only that, please split IPv6 and IPv4 filters, at least if these are
>>> prone to frequent changes.
>>>
>>>> Especially when doing IRR filtering, one simply lets bgpq4 generate the
>>>> filters
>>>> and then drop those definitions into a bird include file, and generate the
>>>> peers parts too.
>>>
>>> When doing IRR filtering, please export it as JSON and load it through RTR
>>> mechanism. We support multiple ROA tables and this is exactly the use case
>>> for it
>>
>> Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data
>> (what rpki-client generates from ROAs) ?
>>
>> As yes, RPKI data we generate into a JSON file and then pass that to a RTR
>> which serves it up to bird; but IRR data becomes filter statements ("bgpq4
>> -b" ;) )
>
> Of course I mean IRR data. You setup two caches, one for actual RPKI data,
> and another one for IRR data, feed it by SLURM, load both by two "protocol
> rpki" instances into two different "roa[64] table"s and call "roa_check()"
> twice.
Took a bit to wrap my mind around, but yes, I gotcha!
The clue in the tutorial was that 'protocol rpki' should have been 'protocol
rtr' ;)
Thus the idea is to produce a "IRR" SLURM file with:
```
{
"slurmVersion": 1,
"validationOutputFilters": {
"locallyAddedAssertions": {
"prefixAssertions": [
{
"asn": ,
"prefix": "",
"comment": "IRR-data"
},
```
and instead of RPKI where we check:
```
roa_check(rpki4, 192.0.2.0/24, originasn) # (where ', originasn' is default
and thus normally omitted)
```
we check:
```
roa_check(irr4, 192.0.2.0/24, peerasn)
```
which means every peer is more or less the same as the peerasn is a parameter
to whatever peer check function one calls and that then just calls the above
roa_check(...peerasn), thus a lot less config and thus more readable and
maintainable. (even if generated, as it gets repetitive).
a quick stab at generating the slurm file:
```
#!/bin/bash
set -e
cat <
Re: Defines for mixed IPv6/IPv4
> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>
>
>
> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
> wrote:
>>
>>
>>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
>>> wrote:
>>>
>>>
>>> Hello bird users,
>>>
>>> I am wondering how you handle matching both IPv6 and IPv4 prefixes
>>> efficiently.
>>>
>>> We have tons of blocks in our config like these:
>>
>> Generate the configs.
>
> Not only that, please split IPv6 and IPv4 filters, at least if these are
> prone to frequent changes.
>
>> Especially when doing IRR filtering, one simply lets bgpq4 generate the
>> filters
>> and then drop those definitions into a bird include file, and generate the
>> peers parts too.
>
> When doing IRR filtering, please export it as JSON and load it through RTR
> mechanism. We support multiple ROA tables and this is exactly the use case
> for it
Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data (what
rpki-client generates from ROAs) ?
As yes, RPKI data we generate into a JSON file and then pass that to a RTR
which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b"
;) )
Greets,
Jeroen
Re: Defines for mixed IPv6/IPv4
> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users > wrote: > > > Hello bird users, > > I am wondering how you handle matching both IPv6 and IPv4 prefixes > efficiently. > > We have tons of blocks in our config like these: Generate the configs. Especially when doing IRR filtering, one simply lets bgpq4 generate the filters and then drop those definitions into a bird include file, and generate the peers parts too. For variations/options, generate those options too based on the input ASN/peer. Use your favourite configuration management tool or use something like: https://github.com/coloclue/kees That does all of it already (bgp4 and uses peeringdb for peers), YMMV for what tool to use (eg. I got my own little thingy for it). Greets, Jeroen
