Thank you, this is exactly what I needed!
Just made a simple bash script to clean BGP and it worked. Quite sure it
could be better, but for my case it is good enough :)
#!/bin/bash
birdc sh pro | grep start | grep dynbgp | cut -d " " -f1 | while read
line || [[ -n $line ]];
do
birdc disable
Hello!
IIRC, the right way to do it is to call
disable X;
for X in all protocol names you want to clear, and then request
reconfiguration which should clear them.
BTW thank you for pointing at this feature. There is currently no
automatic test suite for dynamic BGP and we should
Hi,
I use Bird 2.0.9 to spread a special list of prefixes via BGP to an unknown
list of users, so I use “neighbor range 0.0.0.0/0 external;” and a passive
mode.
In this situation, there are some dynamic protocols created by port
scanners or some other one-time connections. It is not a big deal,
Hi Ondrej,
On Sun, Mar 12, 2023 at 01:29:23PM +0100, Ondrej Zajicek wrote:
> I do not really get this. For multicast, outgoing interface is defined by
> setsockopt(IPV6_MULTICAST_IF) in sk_setup_multicast6().
Hmm, I hadn't seen that. That is odd indeed.
Looking at this again I also noticed we
On Sat, Mar 11, 2023 at 06:28:58AM +0100, Daniel Gröber wrote:
> Hi,
>
> I'm using bird as a replacement for radvd since the latter has a
> longstanding issue with sending adverts on unconfigured interfaces under
> complex conditions.
>
> Turns out bird has a similar issue :)
>
> Looking at the
On Sun, Mar 12, 2023 at 02:36:50PM +0100, d...@darkboxed.org wrote:
> I noticed something in tcpdump just now, when using -iany the incorrect RA
> advert shows up as an "M" (multicast) as opposed to "Out" on the correct
> interface. This only happens when sending an RA on enp2s0 not any of the
>
> The field sin6_scope_id should be used only for link-local addresses (to
> define their scope), not as a way to route multicasts.
>
> (Hmm, ff02::/16 is defined as link-local multicast address, so perhaps
> setting sin6_scope_id makes sense.)
FWIW, babeld uses the sin6_scope_id when sending
Hi Ondrej,
It looks like made a mistake when testing my patch. It does in fact not fix
the problem. I then did some more reading of the linux scriptures and it
turns out PACKET_OUTGOING ("Out" in tcpdump) should actually be reliable so
that meant that the "M" means that packet is actually coming