Re: RFC 9234 (BGP roles) possible bug

[Mikhail Grishin]

Hi,

Thanks.

I'll also remind you the idea to show in Bird CLI
not
Last error:   BGP Error: Role mismatch
but
Last error:   BGP Error: Role mismatch (provider)

In some of previous conversations you accepted it.

Ondrej Zajicek пишет 11.05.2023 18:27:


In the logs printed Error: Role mismatch (provider)
Hi

Yes, it is a bug in BIRD. When BGP capability option is parsed, the
capability structure is initialized with the proper default value, but
when there is no BGP capability option altogether (like in these case),
the capability structure is just zeroed. Unfortunately, RFC 9234 is the
only supported capability that has non-zero default value (0xff), zero
is 'provider'. Will fix that.

I am surprised that in 2023 there are still BGP routers not supporting /
sending capabilities :-) .

RFC 9234 (BGP roles) possible bug

[Mikhail Grishin]

Hi,

We ran BGP roles at 1000+ BGP sessions.
About 0.5 - 1% of them affected by some issue. Probably all of them - 
Juniper with the old junos.


Here is description:
1) Our device (Bird) sent BGP Open to the peers, with
Capability: BGP Role
Type: BGP Role (9)
Length: 1
Unknown: 01

2) Some "broken?" peers respond with:

Border Gateway Protocol - OPEN Message
Marker: 
Length: 29
Type: OPEN Message (1)
Version: 4
My AS: x
Hold Time: 90
BGP Identifier: 10.5.5.2
Optional Parameters Length: 0
Border Gateway Protocol - NOTIFICATION Message
Marker: 
Length: 21
Type: NOTIFICATION Message (3)
Major error Code: Cease (6)
Minor error Code (Cease): Connection Rejected (5)

3) After that, Bird genarates another packet:
Border Gateway Protocol - NOTIFICATION Message
Marker: 
Length: 21
Type: NOTIFICATION Message (3)
Major error Code: OPEN Message Error (2)
Minor error Code (Open Message): Unknown (11)

About stage 2) - peer (old junos) shouldn't generate such response due to
===
If a BGP speaker receives from its peer a capability that it does not
   itself support or recognize, it MUST ignore that capability.  In
   particular, the Unsupported Capability NOTIFICATION message MUST NOT
   be generated and the BGP session MUST NOT be terminated in response
   to reception of a capability that is not supported by the local
   speaker.
===

At the same time, question to the stage 3) - why Bird gererate such message?
+ In the logs printed Error: Role mismatch (provider)

Wbr, Mikhail.

Re: Adding more then one bgp community at once

[Mikhail Grishin]

Hi,

I tried the same at BIRD 2.13 . It reports  "Can't add set".

At the same time in docs
--
|add(/C/,/P/)| adds pair (or quad) /P/ to clist /C/ and returns the 
result. If item /P/ is already in clist /C/, it does nothing. /P/ may 
also be a clist, in that case all its members are added; i.e., it works 
as clist union.

---

What did I miss?

Ondrej Zajicek пишет 28.02.2017 3:49:

On Mon, Feb 27, 2017 at 08:04:41AM +, Борис Коваленко wrote:

Hello!


Is this possible to add many communites at once?
bgp_community.add([(1,1), (1,2)]) is wrong "Setting clist attribute to
non-clist value"

No, this is not implemented (although it makes sense). You have to add
each community independently. But the code should generate a different
error message ("Can't add set"), that seems like bug.

Re: Scaling BFD support

[Mikhail Grishin]

Arnold Nipper пишет 24.06.2022 12:32:

On 23.06.2022 23:41, Douglas Fischer wrote:


Are there any public docs or references of that workshop?



Not yet, Douglas



Sincerely, what caught my attention was the "Auth: none" part.
On a room with more than thousand persons, confirm if the voice you 
rear is really from the person you think it is makes sense to me.




Well, on an IX LAN, you should know how is talking to you ;-) Requring 
auth doesn't add any security IMO.




But the good part is that the interval is not crazily small as some 
wanted.

This reduces the number of pps the deamon has to deal with.

Using the biggest IXP in number os participants as a reference.
Assuming all participants active BFD, there are 2500 BFD session per 
server per protocol(v4+v6)
Assuming that the minimum interval(500ms) is always used(worst case 
scenario).

2750*2*=11.000pps
I don't know if that is feasible for an engine without any 
improvements of performance.




The smaller IXes may go for 500ms. The bigger ones probably will not 
do. And unlike BGP, BFD always goes with the higher interval timer.


Hi,

It also up for customers wishes. We provide selective BFD timers.
Some of IXP members local , some 1000+ kilometers away. Some "requires" 
sub-second failure detection (you need to think about your 
infrastructure to support this).


95+% agree with our default values.

Wbr, Mikhail.




Arnold


Em qui., 23 de jun. de 2022 às 08:52, Arnold Nipper > escreveu:


Douglas

there was a workshop on "BFD at IXes" at the recent Euro-IX Forum in
Tampere.

These are the parameters the participants agreed upon

   * Interval: 500ms - 1500ms
   * Multiplier: 3 or 5
   * Passive: on
   * Idle_tx: 3x Interval
   * Auth: none


Greetings
Arnold

On 18.06.2022 13:47, Douglas Fischer wrote:
 > Hello all!
 >
 > Just passing here to see if any moves on this BFD Scaling 
occurred.

 >
 > This week some friends that are involved in the operation of a
really
 > big IXP told me that they were having problems with some "funny"
 > participants of its IXP that adjusted their BGP Timer to numbers
like 5/15.
 > On an environment with thousands of peers, I'm sure you can
imagine the
 > CPU impact of that.
 >
 > Now you are probably asking:
 > What that has to do with Scale the BFD capacities on BIRD?
 >
 > Well...
 > Those 'j'enius are probably adjusting the timers to have some
kind of
 > control of some communication issue occurs between his router and
the RS.
 > They just "forget" that on that level of reduction, it
compromises the
 > processing capacity of the RS.
 >
 > If BFD engine could support session for every participant at IXP,
or at
 > least for those that wants that kind of resource.
 > Then would be reasonable to lock the timers of BGP Session in 
60/180.

 >
 >
 > Em sex., 1 de abr. de 2022 às 13:41, Ondrej Zajicek
 > mailto:santi...@crfreenet.org>
>>
escreveu:
 >
 > On Fri, Apr 01, 2022 at 08:44:50AM -0300, Douglas Fischer 
wrote:
 >  > The question raised by colleague Irene reminded me of a 
topic

 > that may or
 >  > may not be the focus of BIRD's development.
 >  >
 >  > I imagine that the biggest supporters of
SMP/Multi-Core/Thread-Safe
 >  > evolution on BIRD are Operators of Route-Servers of large
IXPs, and
 >  > operators of large-scale Route-Reflectors.
 >  >
 >  > Although BFD has its greatest use in the transport 
network and

 > Underlay, it
 >  > is increasingly common to see the use of BFD in BGP 
Internet.

 >  >
 >  > I'm personally overly excited about what BIRD version 3 is
 > demonstrating in
 >  > terms of vertical scalability.
 >  >
 >  > But I keep imagining that, even having scalability in 
the BGP

 > engine, it is
 >  > almost prohibitive to use BFD in a scenario with a
thousand BGP
 > Peers.
 >  >
 >  > Is there any view from the IBRD development team for this
matter?
 >  > Or even... Is there any open project focused on BFD 
that can

 > address this?
 >
 > Hmm, that is a good point. It would make sense to have
multiple BFD
 > threads, but i think that it is more a question of improving
I/O loop
 > performance in BIRD, as thousand peers with 100ms period is
about 10
 > kpps
 > UDP rate, which should be manageable even from a single
thread. We
 > should
 > make some effort to do some benchmarking for BFD.
 >
 > --
 > Elen sila lumenn' omentielvo
 >
 > Ondrej 'Santiago' Zajicek (email: 

Re: ignore max length as an argument of roa_check

[Mikhail Grishin]

Hi,

We use this option in production environment (2.0.7 with patches) , 
started in 2020.


Some side effects: Doubled number of tcp sessions with validator, 
doubled number of roa tables (per each BIRD instanse).


Wbr, Milkhail,
MSK-IX

Douglas Fischer пишет 30.03.2021 16:04:

It does make sense! A LOT!

It is the only way I see that is possible to use RPKI as a source of 
information to validate RTBH with the available information existent now.


P.S.: I even mentioned some about that on SIDROPS
https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/

That is the same concept that is used on IRR, right?
"If is BlackHole route is contained on the Route Objects on IRR, is 
acceptable..."


Em dom., 28 de mar. de 2021 às 10:42, Pier Carlo Chiodi 
mailto:pie...@pierky.com>> escreveu:


Hello,

first, thanks to the devs for 2.0.8!

I see the option 'ignore max length' was introduced, and that it's
possible to enable it at protocol configuration time.

ignore max length switch

Ignore received max length in ROA records and use max value
(32 or 128) instead. This may be useful for implementing loose
RPKI check for blackholes. Default: disabled.

I was wondering what other people's feelings would be about having
a similar option available at validation time, more specifically
as an argument of roa_check.

If my understanding is correct, being the current option available
only at protocol level, it means that all the ROAs that are
present inside the ROA table are used as if the maxLength
attribute is not set. This means that it wouldn't be possible to
configure a filter to perform a strict OV check (where the
maxLength is also taken into account) using ROAs from that table.

Having that option available at roa_check time, the same table
could be used to perform both strict validation and also a loose
validation, for example depending on the presence of the BLACKHOLE
BGP community:

(pseudo-code follows)

# ... regular sanity checks done here...

if BLACKHOLE {
if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then
{
reject;
}
accept;
} else {
if (roa_check() = ROA_INVALID) then
{
reject;
}
accept;
}

(Assuming ignore_max_lenght has default value == False.)

Does it make sense?

Thanks

Pier Carlo Chiodi



--
Douglas Fernando Fischer
Engº de Controle e Automação

Re: BIRD2 BFD only listen on IPv6 or IPv4

[Mikhail Grishin]

Ondrej Zajicek пишет 06.11.2020 6:59:

On Thu, Nov 05, 2020 at 05:12:18PM +0100, Stefan Plug wrote:

Hey guys,

BIRD2 2.0.7

I want to run 2 BIRD2 Daemons, one with ipv4 config and one with ipv6 config, 
just like as with BIRD1 this works fine for BGP.

Is there a way to tell BIRD2 to only listen to ipv4 or ipv6 with BFD?

Hi

Not supported in 2.0.7, there is commit 
7f9adafc109d576d5249c25ef284606dbac4adfa for it in master branch.



Hi,

We use this patch in production environment starting this spring, all is 
fine.

Re: RPKI support without SSH transport

[Mikhail Grishin]

Hi,

In my case all compiled fine:

./configure --disable-libssh
.


CC -o obj/proto/rpki/ssh_transport.o -c proto/rpki/ssh_transport.c
CC -o obj/proto/rpki/transport.o -c proto/rpki/transport.c
CC -o obj/proto/static/static.o -c proto/static/static.c


Clemens Schrimpe пишет 19.03.2020 16:44:

Hello and sorry for the late feedback ... lots of things going on ...


On 14. Jan 2020, at 16:45, Maria Matějka > wrote:


however, attempts to build it without /--disable-libssh/ result in a 
linking error:


Oops, sorry, I missed one include. Here is the fixed patch, now it 
compiles both with and without libSSH.


Maria



No, unfortunately it does not - not any more, at least:

Configured with

./configure --disable-libssh

it doesn't compile /proto/rpki/ssh_transport.c /because it references 
"struct ssh_sock" and "SK_SSH_CONNECT", whose definitions are excluded 
in lib/socket.h unless HAVE_LIBSSH is defined →


CC -o obj/proto/rpki/ssh_transport.o -c proto/rpki/ssh_transport.c
proto/rpki/ssh_transport.c: In function 'rpki_tr_ssh_open':
proto/rpki/ssh_transport.c:29:40: error: invalid application of
'sizeof' to incomplete type 'struct ssh_sock'
   sk->ssh = mb_allocz(sk->pool, sizeof(struct ssh_sock));
^~
proto/rpki/ssh_transport.c:30:10: error: dereferencing pointer to
incomplete type 'struct ssh_sock'
 sk->ssh->username = ssh_cf->user;
  ^~
proto/rpki/ssh_transport.c:34:20: error: 'SK_SSH_CONNECT'
undeclared (first use in this function)
   sk->ssh->state = SK_SSH_CONNECT;
^~


Again: Thanks for your great support!

Clemens

Re: Community for small IX - problem with 4B ASN

[Mikhail Grishin]

Hi Piotr ,
May be the most simple thing - to change your ASN number to 16bit - in 
case if solid % of your customers support and use only traditional 
communities (RFC 1997) .


RIPE can help.

Piotr Marciniak пишет 22.01.2018 18:46:

Hello Ondrej,

I am seeking for a way to make our small local IXP project to be a bit 
more flexible and safe. I think we could do with implementation of 
communities which would allow our peers to prepend or block their 
prefixes from annoncing to specific peer or all peers.


Goal is simple. Peer A should be able to send to us community to 
prepend or block announcing his prefixes to chosen by ASn Peer B or 
all peers.


Which community standard I would like to use? Most supported on 
typical, (mosttly) local ISP BGP routers - from Mikrotik by Cisco to 
Bird. I do not think it is extraordinary wish. ;-] Rather typical for 
most IXP of any size.


In our scenario we rather do not need to forward communities. Just to 
collect info from Peer A what to do with his prefixes before 
announcing it to others.


I think the only problem I am facing now is that I can't use in known 
config examples our AS205082. But here we face another problem if I 
understand correcttly - what to do if not only our community is 4B? I 
may "shrink our" to any 16-bit equivalent like 65250 I use in my 
examples. But stil if I have a peer with AS123456 - how to accept his 
4B AS in communities received from our peers? Fe. old Cisco can 
connect to 4B ASn but can't work on 4B communities I think. So it 
can't send me request - do not announce us to AS123456.


But I think second problem is not very important for me. If someone 
cannot send 4B community so.. it is a pitty for him. My problem is to 
let people know what we can accept and process if they wish and can 
send us their preferences. Thus - I need to work with 4B communities 
in most common way possible.


So yes - I would be happy to find an example which would work with 4B 
extended communities both - for myas and peeras sides. If I am right 
with SIXT example - bgp_ext_community are supported for peeras? If yes 
- the only problem is myas which still can't be 4B. But I may replace 
it with fake-16bit-pseudo-myas ;-]. All should be working then?


Best wishes,

Peter



-Oryginalna wiadomość- From: Ondrej Zajicek
Sent: Monday, January 22, 2018 4:16 PM
To: Piotr Marciniak
Cc: bird-users@network.cz
Subject: Re: Community for small IX - problem with 4B ASN

Well, that depends on exact meaning of 'communities'. There are three
different independent community attributes:

- 'traditional' communities (RFC 1997)
- Extended communities (RFC 4360)
- Large communities (RFC 8092)

Attribute bgp_community is for traditional communities, which are limited
to 16 bit components. So you cannot use 32bit ASNs with them. Also, even
if you used 16bit private ASN as myas, you cannot use them for 32bit
peeras.

You can use Extended communities (and that is usual setting in IXes),
but they can have one component 32 bit, but not both. So if you have
16bit myas, you could have 32bit peeras.

Or you can use new Large communities, which are fully 32bit, and ditch
both traditional and Extended communities. But this is pretty new
standard and i am not sure how widely is supported by other systems.

Re: Decode BGP Shutdown Communication messages (RFC 8203)

[Mikhail Grishin]

Hi,

1) You also implemented
enable bgp2 "enable message"
This message currently seen only at local side and doesn't seen at
remote peer.

Scenario: You made maintenance work with the shutdown message "Session
will be down from 13:00 till 14:00".
Later session was established again. Days after at remote peer side
still printed the same message. That's confusing.

Suggestion:
(May be) To show two different messages? Tx and Rx.
To clear Rx message every time when BGP session state  changed to
established.


2) Is it possible to log such messages and see via syslog?

P.S. For russian UTF8 text 128 bytes restriction (RFC) probably not
always enough.


Ondrej Zajicek пишет 19.09.2017 21:53:

On Thu, Jul 27, 2017 at 05:55:40PM +0200, Job Snijders wrote:

Hi all,

Here is a patch to decode received BGP shutdown communication messages
as specified in RFC 8203. In the following example scenario I'm sending
a shutdown communication with openbgpd:

$ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, back in 
30 min"
request processed

Hi

Merged with some significant changes, with support for both RX and TX of
shutdown communication:

https://gitlab.labs.nic.cz/labs/bird/commit/cd1d99611e445c9fe2452d05627ccfc624f35c39

I generalized it a bit, so the message is not specific to BGP, but can be
attached to any protocol, so it makes sense that it can be changed by
general commands like disable, restart. That means it also changed the
output a bit:

bird> show protocols all bgp2
name prototablestate  since   info
bgp2 BGP  master   down   19:39:00
   Description:My BGP session
   Message:Planned shutdown, back in 30 min
   Preference: 100
   Input filter:   ACCEPT
   Output filter:  (unnamed)
   BGP state:  Down
 Neighbor address: 10.0.1.1
 Neighbor AS:  10

Conceptually, it is one-item mailbox, which can be set by either the core
(using enable/disable/restart commands) or the protocol (received BGP
Notification with the RFC 8203 message). I am not sure if it would not be
better to have two separate mailboxes for both directions, but it
probably does not matter.

The message can be send from BIRD shell:

birdc> disable bgp1 "hi, we will upgrade to bird 1.6.4"

Unfortunately, that means that from Unix shell you have to do double qouting:

birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"'

Currently no support for message associated with 'disabled' in bird.conf
or for message associated with BIRD global shutdown.


Otherwise, there are some minor changes w.r.t. your patch:

1) Your patch requires that RFC 8203 message fills the entire space of
BGP notification (i.e. msg_len + 1 == remaining_len). I do not see any
such requirement in RFC 8203, so i accept if (msg_len + 1 <= remaining_len)

2) I reset the message not with any RX notification, but only with
administrative shutdown/reset notification. That prevents message reset
with subsequent errors unrelated to administrative notification.

3) Proper handling of zero-length messages (should be handled equally
like no message at all according to RFC 8203).

4) Some basic sanitization of received strings to avoid escape-attacks
and newlines in logs.

Any comments, suggestions, opposition?

Re: BGP Monitoring Protocol (BMP) support in Bird?

[Mikhail Grishin]

Hi Ondrej,

Is there any news/updates about BMP support in Bird?

Ondrej Zajicek пишет 04.07.2016 12:36:

On Tue, Jun 28, 2016 at 05:21:19PM +0200, Baptiste Jonglez wrote:

Hi,

I am wondering if somebody is working on BGP Monitoring Protocol (BMP)
support in Bird?

Hi

We are not currently working on it, but we are discussing it and it is
something we might start soon.