Re: Feature request: static routes to not directly connected gateways
On Wed, Oct 22, 2014 at 08:10:06PM +0200, Alexander Demenshin wrote:
> Hi,
>
> It would be nice to be able to use "indirect" gateways, i.e. which are
> routed via interface but are not part of interface networks, like this:
>
> protocol static {
> route 10.1.1.0/24 via "eth0";
> route 10.2.1.0/24 via 10.1.1.1;
> }
Hi
This works, but the route must have special 'recursive' nexthop. In that
case its nexthop is resolved through the table and found route is used
for nexthop, combined with the original nexthop in the case where found
nexthop is a device:
protocol static {
route 192.168.90.0/24 via 192.168.81.1;
route 192.168.91.0/24 recursive 192.168.90.10;
}
bird> show route
192.168.81.0/24dev eth0 [direct1 21:56:40] * (240)
192.168.90.0/24via 192.168.81.1 on eth0 [static1 21:57:36] * (200)
192.168.91.0/24via 192.168.81.1 on eth0 [static1 21:56:40] * (200)
protocol static {
route 192.168.90.0/24 via "eth0";
route 192.168.91.0/24 recursive 192.168.90.10;
}
bird> show route
192.168.81.0/24dev eth0 [direct1 21:56:39] * (240)
192.168.90.0/24dev eth0 [static1 22:00:20] * (200)
192.168.91.0/24via 192.168.90.10 on eth0 [static1 22:08:54] * (200)
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: Prefix for BIRD maillist emails
On Thu, Oct 16, 2014 at 05:16:16PM +0100, Fernando Frediani wrote: > Hi chaps, > > Just an small cosmetic detail to whoever is responsible for the mail list. > Perhaps would be nice to have on every email subject sent by the Maillist > system the Prefix [BIRD] or [BIRD-Users] to identify more clearly the > incoming emails. > Would it be possible to consider it ? Hi Well, that is probably not a good idea w.r.t. current DKIM / DMARC movement - modifying subject may lead to break DKIM signature and rejecting the mail in some circumstances. Generally, the proper way is to identify mails from mailing lists by their List-ID header, which, as i checked now, is missing here and should be added. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Multiple OSPF instances on one interface
On Fri, Oct 10, 2014 at 08:48:36AM +0200, Tore Anderson wrote:
> Hi,
>
> I'm trying to run two instances of OSPFv3 on a single interface, one in
> stub mode, the other in normal broadcast mode. It doesn't seem to work,
> in one of the protocols the interface ends up being marked "down". I
> don't see why that would be, since one of the instances is in stub mode,
> there should be no conflict between the two instances.
Generally, the interfaces must use different instance id to be shared
between instances. Although it is true that there is no real conflict if
the interface is in stub mode, it is not taken into account.
Just set the instance id on stub:
interface "eth0" instance 1 {
stub yes;
};
(Or better, you could set common instance id for the whole special-use
ospf instance, but that would have to be used consistently on all routers
in given OSPF domain.)
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: bird's not forwarding point-to-point routes via OSPF
On Wed, Oct 15, 2014 at 11:00:03AM -0700, Noel Burton-Krahn wrote: > Is there something about point to point addresses that could keep bird > from forwarding them? I'm assigning a point-to-point address to a > veth pair like so: > > ip link add veth1 type veth peer name veth2 > ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1 > ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2 > > Neither of those addresses get forwarded via OSPF to other hosts. > They *do* get forwarded if I add the addresses without a peer like > this: > > ip addr add 10.0.0.1/32 dev veth1 > > Now I've added the same address (10.0.0.1/32) to veth twice, and bird > is forwarding a route for that address to OSPF peers. > > Is there a way for bird to accept the "peer" address? I tried "learn" > in the kernel but that didn't help. .. also .. On Fri, Oct 10, 2014 at 12:05:30PM +0200, Thomas Goldberg wrote: > Hello, > > we've OSPF running over a openvpn ptp tunnel and some problems with > the routes injected by bird (v1.4.5). ... > Shouldn't bird inject routes like this on the corresponding router > (without having to learn them via the direct protocol)? > 10.176.3.29/32 dev lo [o_internal 2014-10-09 00:00:00] * I (150/0) > [10.176.3.29] Hello This is IMHO the same issue. It is an intentional behavior, BIRD does not inject local address for links with peer addresses, mainly based on idea that links with such addresses are just variants of 'unnumbered' ptp links and these addresses are just general 'loopback' addresses and are usually also used on other interfaces (like the explicit loopback interface) [*]. Also note that it is usually simpler to add wanted addresses (using explicit loopback interface or using 'stubnet' option) in use cases where they should be propagated than remove unwanted addresses in use cases where they should not be propagated. But in retrospect i am not sure if this behavior was really a good idea. Perhaps automatic adding of host routes should be configurable and enabled by default for peer addresses to ensure that all addresses on OSPF-enabled interfaces are reachable in OSPF area. Any comments (esp. arguments for or against it) to this issue? [*] i.e. configuration like: ip addr add 10.0.0.1/32 dev lo / dummy0 ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev eth0 ip addr add 10.0.0.1/32 peer 10.0.0.3/32 dev eth1 ip addr add 10.0.0.1/32 peer 10.0.0.4/32 dev eth2 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: OSPF route selection
On Wed, Oct 08, 2014 at 01:28:43PM +0200, Olivier Benghozi wrote: > Hi , > > it should be noted that the RFC 2328 explains in its annex C.1 that the > "RFC1583Compatibility" flag must be "Set to enabled by default". Thanks, i never noticed that. > The critical thing is having that configuration consistant across the > network (default values sometimes suck), and understanding what is done > (if set to off, the particular loop case design must be avoided). This is probably a typo, but the loop case must be avoided when RFC1583Compatibility is enabled, not when it is turned off. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: OSPF route selection
On Tue, Oct 07, 2014 at 06:14:15PM +0200, Thomas Goldberg wrote: > Hello, > > we're using OSPF for anycast routing and came across a small problem. > > We've a BIRD v1.4.4 router which sits in area 0 and 16. > Here's the relevant state information (10.236.144.144/32 is announced > from two different routers in two areas): > > area 0.0.0.0 > router 10.236.144.241 > distance 33 > external 10.236.144.144/32 metric 1 > > area 0.0.0.16 > router 10.17.224.253 > distance 111 > external 10.236.144.144/32 metric 1 > > The route via area 16 is considered best: > 10.236.144.144/32 via 10.176.3.29 on vlan542 [o_internal 2014-10-07 > 16:49:56] * E1 (150/112) [10.17.224.253] > > Given that both E1 routes are reachable via intra-area paths. > We're wondering why the path via area 16 (higher costs than area 0) is chosen. > Is this the intended behavior? Surprisingly yes, see RFC 2328 16.4. (6c) and 16.4.1.: 16.4.1. External path preferences ... The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. > Is there any way to make bird prefer routes via a specific/backbone > area in a situation like this? You could enable 'RFC1583Compatibility' option, but that is generally discouraged unless you know exactly what you are doing (as it may lead to persistent routing loops). Or you could use external routes with different E2 metric, in that case lower E2 metric is always preferred. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] bird.init: Added a check_config function and call it prior of, start and reload
On Mon, Oct 06, 2014 at 11:35:44PM +0200, Pavlos Parissis wrote: > On 06/10/2014 11:18 μμ, Ondrej Zajicek wrote: > > On Sun, Oct 05, 2014 at 09:47:08PM +0200, Pavlos Parissis wrote: > >> Hi, > >> > >> This another patch for the init script which adds a check_config > >> function and call it prior of, start and reload. > > > > Hi > > > > Why to do this? > > Because it is needed for integration with configuration management > tools(Puppet, chef and etc). Without the patch these tools are unaware > that they just pushed a broken configuration. Bird operation is not > effected as it doesn't load broken configuration. > > > Explicit checking of config has some specific use cases > > but it is IMHO pointless in standard init scripts. If we need return > > values (to see if BIRD was properly started or reconfigured), we should > > get proper return values from the primary commands (that means that > > 'birdc configure' should be used for reconfiguration instead of sending > > HUP and i should ensure that birdc returns proper error code) > > > > I was wondering why init script was not calling birdcl configure rather > sending HUP, but I guess because it is not actively used/maintained. > > What would be the consequence of sending HUP rather calling birdcl > configure, if any? AFAIK the only consequence is that you cannot get the return value and eventual error messages are handled differently (send to the log instead of returned to birdc). I just checked that birdc/birdcl does not forward the return value, but that is something that probably should be fixed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] bird.init: Added a check_config function and call it prior of, start and reload
On Mon, Oct 06, 2014 at 11:05:01PM +0200, Pavlos Parissis wrote:
> On 06/10/2014 06:05 πμ, Dmitry S. Nikolaev wrote:
> > Hi.
> >
> > Thanks for patch but hardcoded path:
> >
> > /usr/sbin/"${_bird}" -p -c /etc/"${_bird}".conf
> >
> > It`s not good for (such as) FreeBSD users.
> >
> > # whereis bird
> > bird: /usr/local/sbin/bird /usr/ports/net/bird
> >
> > Default path to config: /usr/local/etc/bird.conf /usr/local/etc/bird6.conf
> > I use path to config: /usr/local/etc/bird/bird.conf
> > /usr/local/etc/bird/bird6.conf
> >
>
> But there are already paths hardcoded in the init script I found on the
> repo. I failed to find any other scripts and I don't have access to BSD
> systems. Does the current script work on BSD?
I don't think so, it is not even used in Debian. I mostly ignored it as i
was not aware whether it is used anywhere or it is just some historic
relict, but it is probably used in RedHat, i guess?
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: [PATCH] bird.init: Added a check_config function and call it prior of, start and reload
On Sun, Oct 05, 2014 at 09:47:08PM +0200, Pavlos Parissis wrote: > Hi, > > This another patch for the init script which adds a check_config > function and call it prior of, start and reload. Hi Why to do this? Explicit checking of config has some specific use cases but it is IMHO pointless in standard init scripts. If we need return values (to see if BIRD was properly started or reconfigured), we should get proper return values from the primary commands (that means that 'birdc configure' should be used for reconfiguration instead of sending HUP and i should ensure that birdc returns proper error code) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Another Netlink: File exists
On Mon, Oct 06, 2014 at 10:15:51AM -0400, micah wrote:
> micah writes:
>
> Some additional information, I do have a handful of static routes
> defined:
>
> protocol static static_bgp {
> import all;
> route 204.13.164.0/24 reject;
> route 198.252.153.0/24 reject;
> route 199.254.238.0/24 reject;
> }
>
> and these appear in bird as follows:
>
> # birdc show route |grep '!'
> 204.13.164.0/24unreachable [static_bgp 2014-10-04] ! (200)
> 198.252.153.0/24 unreachable [static_bgp 2014-10-04] ! (200)
> 199.254.238.0/24 unreachable [static_bgp 2014-10-04] ! (200)
>
> which I understand is bird trying to add a route to the kernel, but it
> is already there.
Yes, that is exactly the reason for having 'Netlink: File exists' error
message.
BIRD does not rewrite routes that are already in kernel table from other
sources.
If you need them in kernel regardless of BIRD, you can as a workaround
learn these routes from kernel proto and set them higher preference
(using 'preference') than ones from static proto. That would prevent
static routes to be exported to the kernel.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: prefix patterns cannot be defined as constants
On Thu, Oct 02, 2014 at 01:19:29PM +0200, Kai wrote: > Hi there! > > Just noticed that (shorthand and long) prefix patterns cannot be defined as > constants. During a quick search I couldn't find this behaviour documented, > so maybe it might be considered a bug? This is expected. Prefix patterns are not independent entities, it is just a syntax to write prefix set literals. But you could define whole prefix sets as constants. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: bgp router with multi asn's - neighbor config ?
On Mon, Sep 29, 2014 at 02:19:03PM +, Leo Vandewoestijne wrote:
> On Fri, 26 Sep 2014, Kai wrote:
>
> > protocol bgp me_1 {6
> > local 10.0.0.1 as 1;
> > router id 10.0.0.1;
> > neighbor 10.0.0.9 as 9;
> > direct;
> > }
> >
> > protocol bgp me_2 {6
> > local 10.0.0.2 as 2;
> > router id 10.0.0.2;
> > neighbor 10.0.0.9 as 9;
> > direct;
> > }
> >
> > (In fact there are a lot of peers like this one.)
> > This setup doesn't seem to work. It seems as if, with each restart, only
> > on of the two connections comes online, not always the same one. The
> > second connection is rejected when incoming.
> >
> I'm familiar with that collision, so not surprised.
>
> > Which is the mistake I made here? Or does the peer have to have two IP
> > addresses as well?
> >
> Yes, that's very likely the case.
That is true. You have to use two addresses on the other side.
But it would be a good idea to implement it in the future versions.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: Non-default BGP port
On Tue, Sep 30, 2014 at 11:06:46PM +0200, Matthias Waehlisch wrote: > Hi, > > do I see it correctly that the destination port to establish the BGP > session cannot be changed? > > I would really like to have something like > > neighbor 1.2.3.4 port 5001 as 64512; > > > Any reason not to support this? It is oversight. It will be in the next version, based on the patch from João Taveira Araújo: https://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg03485.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: static route multipath problem
On Thu, Sep 18, 2014 at 02:56:32PM +0800, 守得云开 wrote: > can i setup like this, 11, 12 and 13 is the ip of ppp0, ppp1 and ppp2: > -- > route 0.0.0.0/0 multipath > via 10.10.10.11 weight 2 > via 10.10.10.12 weight 3 > via 10.10.10.12 weight 4; This should work > -- > or link this: > -- > route 0.0.0.0/0 multipath > via 10.10.10.1 dev ppp0 weight 2 > via 10.10.10.1 dev ppp1 weight 3 > via 10.10.10.1 dev ppp2 weight 4; We do not currently support 'dev' option here, but you could use this: route 0.0.0.0/0 multipath via 10.10.10.1%ppp0 weight 2 via 10.10.10.1%ppp1 weight 3 via 10.10.10.1%ppp2 weight 4; This is syntax for link-local IPv6 addresses like fe80::1234:5678%eth0, but works also for regular IPv4 addresses. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Shutting down BGP neighbor causes high CPU and many session flaps.
On Thu, Sep 18, 2014 at 03:27:21PM +0300, Javor Kliachev wrote: > Hello, > > We use bird 1.4.2 as route server with multiple RIBs with ~100 BGP active > sessions. > Over one of these sessions, we're receiving ~ 360k prefixes and > re-announcing them to all other sessions. > > By my calculations the total amount of all prefixes in all RIBs is about ~ > 360 and till now everything was OK. > > *But today we have experienced the following issue: * > > When we stopped the session that we received ~360k, BIRD daemon went to 100% > usage and held this behavior for > period of~5-6 min. This event caused а lot of ( but not all ) sessions to > start flapping. > > Here is the output taken from our log during the event: > > Sep 18 10:40:51 rs2 bird: R0_69: Received: Hold timer expired > Sep 18 10:40:51 rs2 bird: R0_69: BGP session closed > Sep 18 10:40:52 rs2 bird: R0_69: Down > Sep 18 10:41:11 rs2 bird: R0_69: Startup delayed by 60 seconds > Sep 18 10:41:45 rs2 bird: R0_69: Incoming connection from 10.0.0.69 (port > 13073) rejected > Sep 18 10:41:59 rs2 bird: R0_69: Started > Sep 18 10:42:36 rs2 bird: R0_69: Incoming connection from 10.0.0.69 (port > 24222) accepted > Sep 18 10:42:36 rs2 bird: R0_69: BGP session established > > The above lines was repeated for all other affected sessions. Hello Thanks for the bugreport. Could you send me the config file, the whole log and information when exactly BIRD went to 100% and then back? Even in permanent 100% CPU load, BIRD shouldn't miss timers for sending keepalive packets. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Multiple routing tables with multiple gateways
On Tue, Sep 02, 2014 at 03:15:54PM +0100, Fernando Frediani wrote: > Thanks for the Ondrej, > I have actually seen this page already and found it pretty useful. My main > doubt still is about how to separate the routes received in different route > tables to tell the kernel of when a request comes from an IP range it goes > out via that specific gateway. That is something that has to be configured statically using 'ip rule' tools outside of BIRD. See http://lartc.org/howto/lartc.rpdb.html -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Does radv protocol (re)scan interfaces on IPv6?
On Tue, Sep 02, 2014 at 08:22:11PM +0100, Alex Bligh wrote: > > On 2 Sep 2014, at 12:52, Ondrej Zajicek wrote: > > > This should work. Could you check whether 'evrradv: Adding interface XXX' > > log message is logged if you enable debug messages for evrradv? > > We've managed to find the cause of the problem, which is deeply strange. > We were disabling duplicate address detection after setting the link up. > If we move this to disabling DAD before setting the link up, the problem > does not arise. Note that this is just *detection* - it wasn't actually > discovering a duplicate address or anything. Yes, i suspected something like that. Generally, when the interface is created or bringed up, link-local address is automatically assigned, but it is marked as tentative, which BIRD ignores. We should probably wait until the the tentative flag for link-local address is removed. I think it probably tries to bind a socket on that tentative address, which fails (although that should be logged). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: bgp router with multi asn's - neighbor config ?
On Thu, Sep 04, 2014 at 12:32:46PM +, Leo Vandewoestijne wrote:
> > > We want to establish a router ('A') announcing two different ASNs
> > > (as1,as2) to it's neighbours. In fact we want to setup three routers A,
> > > B and C, all of them corporately announcing as1 and as2.
> > >
> >
> > You cannot have two BGP relations to a single peer. I see two options:
> >
> You will certainly have to do this on different IP's.
> And actually I only do it with different IP's in different netmasks.
Yes, you can have two BGP sessions between two BGP neighbors if you use
two pairs of IP addresses, IMHO it should work even if all addresses have
the same netmask.
> I think this config is exactly what's requested.
> It was written for use on FreeBSD (using multifib).
> At one point I got collisons, and I did all my best to prevent that (with
> success).
> So probaly you can make it more simple.
> listen bgp address 10.0.1.102 port 179;
> listen bgp address 10.0.2.102 port 179;
I don't think you should have two 'listen bgp' options. AFAIK there is
only one listening BGP socket in BIRD, but it is OK to have it listen on
0.0.0.0 (default value). Incoming sessions are dispatched based on their
source addresses.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: BFD implementation in 1.4.0
On Tue, Sep 02, 2014 at 05:42:15PM +0400, Mikhail A. Grishin wrote: > Ondrej, > > Looks like you misunderstood me. > This is broken not from the BIRD. This is broken from Cisco/Juniper - such > devices inserts wrong SRC IP in BFD packets. > > Do you still need info that you requested? Yes, i misunderstood. In that case i don't need the info. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Limit on kernel table number
On Mon, Aug 25, 2014 at 08:55:02AM -0500, Bryan Duff wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Enjoy! Well, this removes the check, but it wouldn't otherwise work for reasons described here: https://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg02991.html (only lower bytes of kernel table ids would be used) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Multiple routing tables with multiple gateways
On Mon, Sep 01, 2014 at 08:47:14PM +0100, Fernando Frediani wrote: > Hello there, > > Would anyone be able to point me to the right direction in terms of BIRD BGP > config in order to achieve that, specially with regards the main differences > to a Route Server. This example could help: https://gitlab.labs.nic.cz/labs/bird/wikis/Policy_routing -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Does radv protocol (re)scan interfaces on IPv6?
On Mon, Sep 01, 2014 at 12:57:57PM +0100, Alex Bligh wrote:
> I am trying to isolate an issue with the radv protocol running on IPv6
>
> I have possibly the world's simplest radv configuration:
>
> protocol radv evrradv {
> interface "-evrr-00", "evrr-*" {
> max ra interval 4;
> };
> }
>
> The idea here is that the router provides radv information on all interfaces
> with names starting evrr- except evrr-00.
>
> What I am seeing is that if I add another interface, radv does not appear to
> work.
This should work. Could you check whether 'evrradv: Adding interface XXX'
log message is logged if you enable debug messages for evrradv?
Also what you mean by 'add another interface'? The interface is created,
or just bringed up?
If the interface is also created, could you try to wait several seconds
between the interface creation and activation?
Are there any error messages in log?
> A reload produces:
Reload is only for route export/import, not relevant to radv.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: export filter that checks for existance of another route?
On Sat, Aug 30, 2014 at 12:13:30AM +1000, Paul J R wrote: > Hi All, > > First time post, i've been playing with bird for some time, but there is one > thing i cant figure out how to do and that is use the existence of a > specific route as part of a filter. > > for example, if the filter is processing a route to 4.3.2.0/24, check if a > route to 1.2.3.4/32 (exact) exists, if so then accept, otherwise reject. Is > this something that is possible? or do route filters only have the ability > to check against the information thats sent to the filter itself? It is not possible, for several reasons filters could only check each route independently. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: show route all filter ...
On Thu, Aug 28, 2014 at 12:47:24PM +0200, Alexander Demenshin wrote:
> On 2014-08-28 11:12, Mikhail A. Grishin wrote:
>
> >We use special command (see below) to view information regarding
> >prefixes containing particular BGP communities.
>
> You should add "reject" clause:
>
> show route all filter {if (0,48642) ~ bgp_community then accept; else
> reject; } table master
Yes, there is no implicit default action, filter should explicitly either
reject or accept routes. You could also use shorthand:
show route where (0,48642) ~ bgp_community
which is equivalent to:
show route filter {if (0,48642) ~ bgp_community then accept; else reject; }
> to avoid this warning.
>
> Once I did this mistake and got more than 2 millions (!) of log file
> entries, and bird was blocked for ca. 20 seconds...
>
> It would be nice to rate limit repeating messages to avoid such problems, or
> to implement default filter action.
It definitely should be rate limited. All other filter errors are rate
limited, this one i missed.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: BFD implementation in 1.4.0
On Thu, Aug 28, 2014 at 03:39:32PM +0400, Mikhail A. Grishin wrote:
> Hi,
...
> Then we tried to migrate this BFD sessions to our production route servers
> and faced with issues related to our network infrastructure. We have two
> separate IP networks at the same VLAN. Each customer has 2 peering IP: from
> the first IP subnet, and from the second. One IP assigned as primary,
> another as secondary at the same interface on customer side.
>
> Problem:
> Routers of our customers able to communicate in terms of BFD only with Route
> Server located in the same IP subnet with primary IP address on their
> interface. With the Route Server in another IP subnet they can't communicate
> in terms of BFD because SRC IP address for BFD packets is wrong, equal to
> primary IP, not secondary.
Hi
This should work automatically - BFD should use same src, dst IP
addresses as associated BGP session (assuming that BFD session was
requested by BGP and not explicitly configured using 'neighbor' in BFD
protcol).
There are several possible ways how it could be broken, so i need
some info:
1) What is BIRD version and OS (Linux/BSD)?
2) What local IP addresses are reported for BGP sessions?
('Source address' in 'show protocols all')
Correct one or bad one?
3) Is BGP source address explicitly configured in BGP protocol?
('local IP as NUM' instead of 'local as NUM')
If not, could you try to set it and see if anything changes?
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: Limit on kernel table number
On Mon, Aug 25, 2014 at 01:30:30AM +0200, Alexander Demenshin wrote: > Hi, > > It seems that there is a limit on maximum kernel table number (in kernel > protocol), > in particular I couldn't use number 1000 while this is perfectly acceptable > by the Linux kernel. > > Is there any specific reason for this limitation? Hi Yes, BIRD uses older kernel API, which limits kernel table number to 255. This is also assumed in some other parts of BIRD code. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: changes somewhere between 1.3.9 and 1.4.0
On Thu, Aug 21, 2014 at 04:32:22PM +0400, Mikhail A. Grishin wrote: > Hi, > > We found that in 1.4.0 and later versions our approach to see rejected BGP > routes for IXP customers stop working. > > This worked fine in 1.3.9 and earlier versions: > - > [18:44:27]ekt-rsm1% echo 'show route protocol R2854x1' | birdc | wc -l > 238 > [15:58:45]ekt-rsm1% echo 'show route protocol R2854x1 table T2854x1' | birdc > | wc -l > 245 > -- > Diffs between this two outputs - rejected routes. > > At 1.4.0 and later we see the same numbers: > [16:00:26]ekt-rsm2# echo 'show route protocol R2854x1 table T2854x1' | birdc > | wc -l > 245 > [16:08:51]ekt-rsm2# echo 'show route protocol R2854x1' | birdc | wc -l > 245 > > > Can you tell us, what changed? And how to restore old behavior? Hi This is a change in default value of 'table' for 'show route' command, now it is inferred from the protocol or export options (when used). To restore the old behavior just add 'table master' to 'show route' when no table is specified. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Unknown LSA type from x.x.x.x
On Thu, Aug 21, 2014 at 05:11:13PM -0700, Eric Cables wrote: > Running BIRD v1.4.4 > > I'm seeing a lot of these error messages: > bird: Unknown LSA type from x.x.x.x > > Is this anything to worry about? I don't see any issues affecting BIRD, but > it is filling up log files. Probably not, although the other side should not send the LSA if BIRD not signalized that it support relevant extension. Could you check what OSPF implementation is the other side and which LSA is it (e.g. by tcpdump or enabling logging of packets for OSPF)? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Reloading static/direct/device/kernel protocols via birdc fails
On Wed, Aug 20, 2014 at 01:03:12PM +0200, Alexander Demenshin wrote: > Hi, > > When I am attempting to reload kernel, static, direct or device protocol via > birdc, I always get message like this "krt_main: reload failed", > while in the log file I see just reloading message: > > Reloading protocol krt_main > > For pipe, bgp and ospf instances there is only "reloading" message. > > Is this a bug, feature or something else? Hi Reload operation is not implemented in kernel protocol, you have to restart it. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Constants can't contain other constants?
On Thu, Aug 21, 2014 at 05:12:04PM +1200, Michael Fincham wrote: > Hi everyone, > > I'm presently investigating BIRD as a (much appreciated!) replacement for > Quagga and running in to some behaviour that isn't clear from reading the > documentation. > > I'm looking at ways to consistently template BGP communities received from / > sent to peers across multiple routers, and have attempted this: > > define test_international = (test_asn, 90); > define test_national = (test_asn, 100); > define test_ix = (test_asn, 200); > define test_bilat = (test_asn, 300); > define test_customer = (test_asn, 400); > define test_infrastructure = (test_asn, 500); ... > This suggests to me that one cannot define a constant including another > existing constant in this manner? Well, you could generally use constants in constants (you are using test_asn in your example), just the set literals are a bit complicated and do not allow constants for whole pair. > If so, is the best approach instead to > define constants for individual communities and use re-usable 'functions' > to group them logically? You could use: define val_blackhole = 666; define test_send_to_transit = [(test_asn, val_blackhole)]; -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BGP Keepalive timer wedging
On Wed, Aug 20, 2014 at 01:02:27AM +, Chris Caputo wrote: > At the Seattle IX we are using BIRD 1.4.4 for our native (non-VM) route > servers. > > With one particular IPv4 peer, on two different route servers, I am seeing > "Keepalive timer" count down to zero and then becoming wedged/stalled. > Tcpdump fails to show a keepalive message being sent, while it does show > them being received from the peer. ... > with Hold timer getting updated over time, but the Keepalive timer doesn't > change after it has its initial countdown to zero. The peer eventually > signals "ex: Received: Hold timer expired" once it goes 180 seconds > without a BGP update, since it also hasn't gotten any keepalive messages. > > I've looked at the code and haven't found a problem. The other 64 > similarly configured peers on the route server are working fine. > > Has anyone seen this or have any suggestions? Hi I would guess that the problem is in the TCP connection to the peer - BGP packets are sent, not acknowledged, TX queue became full and TX hook is not called anymore (Keepalive timer is restarted in TX hook when previously scheduled Keepalive is sent). You should check whether other packets are propagated (e.g. updates from both sides), esp. when the connection is already in keepalive 0/60 state. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: explicitly setting rte->next = null
On Wed, Aug 20, 2014 at 05:44:28PM +1200, Nic Cave-Lynch wrote: > Hi People > > I've been trying to find a segfault in a custom protocol I've been writing. > I've finally tracked it down to a situation where bgp protocol, in > bgp_rte_update, is calling rte_get_temp but not setting -> next to null, > leaving it at whatever was left in RAM when the memory was allocated. Later, > I see it's not null and try to access the ->next and eventually trigger a > segfault. Generally, rte->next should be set by rte_recalculate() when it is inserted to the routing table and should not be accessed before that. If this causes crash to you, it is probably some other problem in the update path. What are the circumstances when your code accessed rte->next value? It was called regularly from rte_announce()? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Removing device-bound routes when interface is going down
On Mon, Aug 18, 2014 at 08:32:37PM +0200, Alexander Demenshin wrote: > On 2014-08-18 19:54, Sergey Popovich wrote: > > >Summary is that if you have ~500k routes in the BIRD and interface > >where nexthop of such routes changes its operstate kernel should > >sent notification about each of them (~500k). > > I see... thank you - this didn't cross my mind :) > > But nevertheless, what about handling this in bird directly, by watching > for "interface deleted" (not "operstate down"!) event and cleaning up > [kernel linked] routes that use this device? Kernel deletes them anyway. That probably should be implemented. Thanks for the suggestion. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Allowing multiple instances of kernel protocol to use same table
On Mon, Aug 18, 2014 at 02:00:16PM +0200, Alexander Demenshin wrote: > Hi, > > Is there any specific reason why each instance of kernel protocol must use > unique table? Yes, because BIRD keeps some bits of data related to export of routes to the kernel table directly with routes in routing tables (flags KRF_INSTALLED, KRF_SYNC_ERROR, see krt_notify() and krt_replace_rte()). If you just force multiple tables, these bits for different kernel protocols would be mixed. E.g.: You have two kernel protocols K1 and K2 and route R whose export to K1 is accepted but to K2 is filtered. You get: 1) R appeared 2) R is exported to K1, KRF_INSTALLED flag is set for R 3) R is filtered to K2, KRF_INSTALLED flag is unset for R 4) R is removed 5) R withdraw is exported to K1, but because KRF_INSTALLED is not set, K1 do not try to remove R from the kernel and it stays here. So the modification would most likely break proper synchronization when multiple tables are used. Although periodic scans of routing tables may fix it, i wouldn't rely on that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Multihop BGP cannot use direct gateway mode - misidentification of multihop sessions?
On Wed, Aug 13, 2014 at 10:27:01AM +0100, Alex Bligh wrote: > Ondrej, > > On 13 Aug 2014, at 10:03, Ondrej Zajicek wrote: > > > > > In short, the default values depends in this direction: > > > > EBGP|IBGP -> direct|multihop -> gateway direct|recursive > > > > Changing former would change the default value for later, but not otherwise. > > Not sure I understand that. > > The session is IBGP. It is not multihop (by which I mean it's > on the same subnet), but AFAICT bird thinks it is. Generally, by 'direct BGP session' or 'multihop BGP session' i mean the mode of operation of that BGP sesssion; i.e., whether it is expected to be on the same subnet, not whether it is really on the same subnet. The mode of operation cannot be reliably detected from the network topology, because the topology could change during the operation. E.g.: You have BGP neighbor 192.168.1.10 and two interfaces: eth0 with 192.168.1.1/24 and eth1 with 192.168.2.1/24. If the BGP session is in direct mode, it always uses eth0, packets are sent with TTL 1 and the session automatically shutdowns when eth0 is disabled. If the BGP session is in multihop mode, it reaches 192.168.1.10 based on IGP routes, which is probably a direct route through eth0, but could be rerouted by IGP (without dropout of the BGP session) through indirect hop over eth1 when eth0 is disabled. > How do I change it to a 'direct' (as opposed to multihop) session? Use 'direct' option: direct Specify that the neighbor is directly connected. The IP address of the neighbor must be from a directly reachable IP range (i.e. associated with one of your router's interfaces), otherwise the BGP session wouldn't start but it would wait for such interface to appear. The alternative is the think you are saying it's defaulting to a multihop configuration (and > thus 'gateway' defaults to 'recursive'), as opposed to it detecting > a multihop session. > > Also, you cannot (it would seem) change to 'gateway direct' as you get > the error. > > At the very least I think there is a documentation error as > it says 'gateway direct' is the default. It only says that 'gateway direct' is the default for 'direct' sessions, which is true. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Multihop BGP cannot use direct gateway mode - misidentification of multihop sessions?
On Wed, Aug 13, 2014 at 10:52:49AM +0300, Sergey Popovich wrote:
> commit f3e59178506dab9d54cf19ec701f8d9a7fe283f9
> Author: Ondrej Zajicek <>
> Date: Sun Nov 24 12:37:24 2013 +0100
>
> Enables multihop mode for IBGP by default.
>
> Now multihop enabled by default for iBGP sessions (which is your case), but
> can not be turned off with gateway direct so parse error is returned.
Hi
Multihop is now enabled by default for IBGP, but it *can* be turned off.
See below.
> > > From this, gateway direct should be the default for a direct session in
> > > any case. It would appear to me that bird is somehow misidentifying the
> > > session as a multihop session.
Whether the session is multihop or direct is not detected, but it is
configured. In older versions, direct was the universal default. In the
current one, direct is the default for EBGP and multihop is the default
for IBGP.
> BIRD by default uses multihop for iBGP sessions since commit f3e59178506dab.
>
> >From my point of view the core of the problem is that multi hop could
> not be turned off in iBGP configurations, but this is also true on
> othe platforms (cisco, juniper, ...).
Both IBGP and EBGP can be explicitly configured in BIRD to use either
direct or multihop mode (options 'direct' and 'multihop').
The problem here is to mix it with 'gateway direct|recursive' option,
which configures something related but slightly different - just the
aspect of gateway resolution. You generally don't need to use this
('gateway ...') option as its default depend on direct/multihop session
mode. Combination 'multihop' and 'gateway direct' is forbidden, so this
option is useful mainly to set 'gateway recursive' together with 'direct'
mode.
In short, the default values depends in this direction:
EBGP|IBGP -> direct|multihop -> gateway direct|recursive
Changing former would change the default value for later, but not otherwise.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: dmalloc
On Wed, Aug 06, 2014 at 06:15:36PM +1200, Nic Cave-Lynch wrote: > Hi people > > I'm working on a custom routing module and I'm having problems with memory > allocation. I've tried compiling with --enable-memcheck, having installed > libdmalloc (with apt-get install libdmalloc-dev libdmalloc5). > > make now fails as below. > > In lib/resource.h there's a check for libdmalloc which then refers to > _xFOO_leap functions which I guess were once included with libdmalloc, but > they're not there now. > > Is there a way of using libdmalloc, (or some other equivalent) that is > currently operational? I didn't use it, it is pretty possible that compilation iwth libdmalloc is broken. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: next-hop announcement/withdrawal process
On Mon, Aug 04, 2014 at 10:53:27AM +0300, Sergey Popovich wrote: > > > Hi, > > Hello. > > > The problem I am facing is that when I adjust a filter in order to > > withdraw the route, all routes are withdrawn and the remaining are > > announced again. According to the doc if a reload on bird brings a new > > configuration for a protocol, that protocol will be restarted. So, it is > > expected behavior. > > > > You have changed import filter of direct1 protocol, thus direct1 gets > reconfigured (on HUP or birdc configure). However this protocol does not > perform "soft" reconfiguration on filter changes thus direct1 restarts > unconditionally to apply your filter changes (IP removal/addition). > > All routes flushed out from the table (causing BGP withdrawal) and > fetched from the protocol (direct) again to the table (causing BGP update). Yes, that is the reason, direct protocol is limited in this regard. Simple workaround would be to put the filter as export filter to BGP instead of import filter from direct (as in your example). If filtered routes would be needed for more purposes, it is possible to attach direct to separate table and put filters to a pipe connecting these two tables. Just some minor comments: > Also I suggest you to use global prefix set definition, as local variable > (in filter/function) is created/assigned each time function is called. That is not true - (prefix and other) sets are created during parsing of the config file (that is the reason why they are read only and cannot be dynamically parametrized). Although i would usually suggest to put these prefix definitions as global variables anyways. >>> # This may be is needed to properly resolve nexthops from upstream >>> routes. >>> interface ""; > You need this only if you import something from the your routers > (for example default from both routers) to let BIRD correctly > resolve nexthop. This is not necessary since 1.4.0. In the original configuration there is a 'direct' option in BGP template, which also by default chooses the direct (instead of recursive) resolution of next hops (as done by default in EBGP), -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Bring UCI and LUCI configuration for Bird4/6 to improve integration with OpenWRT
On Sun, Jul 20, 2014 at 12:05:39PM +0200, Eloi Carbó Solé wrote: > Hi everyone, > > I am Eloi Carbó, a student from the UPC in Catalonia, doing a Google Summer > of Code [0] with the QMP project [1] team, and the support of Guifi.net [2] > and BMX6 [3] developers and under the scope of Freifunk [4]. > > I would like to inform you that we are bringing UCI and LUCI configuration > support to Bird4 (now) and Bird6 (ASAP) putting our efforts on BGP routing. Hello It would be nice to have UCI configuration in OpenWRT for BIRD. Although I am not sure how filters could be usefully represented in UCI and these are pretty important in most nontrivial BGP configs. I would suggest to keep structure of UCI BIRD configs consistent with native BIRD configs. Although BIRD sometimes uses multiple nesting and i am not sure whether UCI can represent that. Also, please use same option names (when possible) with underscore separator for space instead of camelCase (e.g. scan_time instead of scanTime). That would be consistent with both UCI style and BIRD style. Some comments to /etc/config/bird4: config bird 'bird' option useUCIconfig '0' #Caution! Enabling this option, Bird will translate this #UCI file and use it instead of /etc/bird4.conf option UCIconfigFile '/tmp/bird4.conf' Perhaps '/var/etc/bird4.conf' as default ? config global 'global' option logFile '/tmp/bird.log' Default configuration should probably use syslog instead of logfile. option log 'all' option debug 'all' 'debug all' is not a good default value. That would generate tons of log messages. option table 'arf' 'table' should not be a global option, more like one section for each table (although there is just one option 'sorted' and tables currently do not have block for options in BIRD config, but that will change in the future). config kernel kernel1 option tablePriority '100' This is misnomer. It is not a table priority, just a kernel table ID. config device device1 option scanTime '10' #list primaryIface 'eth0:192.168.1.1' #list primary '192.168.0.0/16' You may ignore 'primary' device option. It is mostly deprecated and not much useful. config bgp bgp1 option table 'arf' option import 'all' option export 'all' option as '65001' option disabled '0' config neighbor option type 'bgp' option instance 'bgp1' option addr '172.16.1.5' option as '65530' In BIRD, we don't have separate neighbors as subsections of BGP. We have one BGP instance per neighbor (also with separate protocol name). UCI structure should probably reflect that too. If you want common options for multiple BGP neighbors, you could use protocol templates for BGP: config bgp_template bgp_common option table 'arf' option import 'all' option export 'all' option locas_address '172.16.1.1' option local_as '65001' config bgp bgp1 option template 'bgp_common' option neighbor_address '172.16.1.5' option neighbor_as '65530' config route option instance 'static1' option type 'general' option addr '192.168.9.0/24' list via '10.99.105.159' Perhaps not use 'list' but 'option' for 'via' in this case. Type should be 'router' which should be default type. option 'addr' should be named 'prefix' instead. config route option instance 'static1' option type 'special' option addr '192.168.2.0/24' option attribute 'unreachable' It is unnecessary to use separate 'attribute' option. You could use 'unreachable', 'blackhole' and 'prohibit' as route types. config route option instance 'static1' option type 'multipath' option addr '192.168.30.0/24' list via '172.16.1.5' list via '172.16.1.6' list viaWeight '172.16.1.2:70' Weight attribute is probably not important enough to implement it with such ugly syntax. For /etc/init.d/bird4, please use 'case' instead of 'if/elif' sequences. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Bring UCI and LUCI configuration for Bird4/6 to improve integration with OpenWRT
On Sun, Jul 20, 2014 at 12:05:39PM +0200, Eloi Carbó Solé wrote: > Hi everyone, > > I am Eloi Carbó, a student from the UPC in Catalonia, doing a Google Summer > of Code [0] with the QMP project [1] team, and the support of Guifi.net [2] > and BMX6 [3] developers and under the scope of Freifunk [4]. > > I would like to inform you that we are bringing UCI and LUCI configuration > support to Bird4 (now) and Bird6 (ASAP) putting our efforts on BGP routing. Hello It would be nice to have UCI configuration in OpenWRT for BIRD. Although I am not sure how filters could be usefully represented in UCI and these are pretty important in most nontrivial BGP configs. I would suggest to keep structure of UCI BIRD configs consistent with native BIRD configs. Although BIRD sometimes uses multiple nesting and i am not sure whether UCI can represent that. Also, please use same option names (when possible) with underscore separator for space instead of camelCase (e.g. scan_time instead of scanTime). That would be consistent with both UCI style and BIRD style. Some comments to /etc/config/bird4: config bird 'bird' option useUCIconfig '0' #Caution! Enabling this option, Bird will translate this #UCI file and use it instead of /etc/bird4.conf option UCIconfigFile '/tmp/bird4.conf' Perhaps '/var/etc/bird4.conf' as default ? config global 'global' option logFile '/tmp/bird.log' Default configuration should probably use syslog instead of logfile. option log 'all' option debug 'all' 'debug all' is not a good default value. That would generate tons of log messages. option table 'arf' 'table' should not be a global option, more like one section for each table (although there is just one option 'sorted' and tables currently do not have block for options in BIRD config, but that will change in the future). config kernel kernel1 option tablePriority '100' This is misnomer. It is not a table priority, just a kernel table ID. config device device1 option scanTime '10' #list primaryIface 'eth0:192.168.1.1' #list primary '192.168.0.0/16' You may ignore 'primary' device option. It is mostly deprecated and not much useful. config bgp bgp1 option table 'arf' option import 'all' option export 'all' option as '65001' option disabled '0' config neighbor option type 'bgp' option instance 'bgp1' option addr '172.16.1.5' option as '65530' In BIRD, we don't have separate neighbors as subsections of BGP. We have one BGP instance per neighbor (also with separate protocol name). UCI structure should probably reflect that too. If you want common options for multiple BGP neighbors, you could use protocol templates for BGP: config bgp_template bgp_common option table 'arf' option import 'all' option export 'all' option locas_address '172.16.1.1' option local_as '65001' config bgp bgp1 option template 'bgp_common' option neighbor_address '172.16.1.5' option neighbor_as '65530' config route option instance 'static1' option type 'general' option addr '192.168.9.0/24' list via '10.99.105.159' Perhaps not use 'list' but 'option' for 'via' in this case. Type should be 'router' which should be default type. option 'addr' should be named 'prefix' instead. config route option instance 'static1' option type 'special' option addr '192.168.2.0/24' option attribute 'unreachable' It is unnecessary to use separate 'attribute' option. You could use 'unreachable', 'blackhole' and 'prohibit' as route types. config route option instance 'static1' option type 'multipath' option addr '192.168.30.0/24' list via '172.16.1.5' list via '172.16.1.6' list viaWeight '172.16.1.2:70' Weight attribute is probably not important enough to implement it with such ugly syntax. For /etc/init.d/bird4, please use 'case' instead of 'if/elif' sequences. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Important bugfix in BGP
On Mon, Jul 21, 2014 at 12:04:27PM +0200, Hans van Kranenburg wrote: > Hi, > > On 07/21/2014 11:55 AM, Mo Shivji wrote: > > > >What was the "Important bugfix in BGP” for 1.4.4 ? > > I guess it's this one: > > https://gitlab.labs.nic.cz/labs/bird/commit/66370eac1f88ec74b3017f1c39038d7b8b776de6 Yes, that is the one. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Equal cost multipath support for BGP
On Mon, Jul 14, 2014 at 07:44:56PM +0300, MrBr @ GMail wrote: > Hello > Is there any way to configure ECMP in BGP? No, that is not supported. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Getting started with OSPFv3
On Fri, Jul 11, 2014 at 02:26:36PM -0400, Daniel Corbe wrote: > I'm trying to get an IPv6 adjacency up and running and I'm having > issues. I'm hoping someone can point me in the right direction here. > When I bring up bird6 I get this: > > Jul 11 18:08:38 router-priamry bird6: main: Cannot find forwarding address > for NSSA-LSA ::/96 > Jul 11 18:08:38 router-priamry bird6: main: Cannot find forwarding address > for NSSA-LSA ::/0 > Jul 11 18:08:38 router-priamry bird6: main: Cannot find forwarding address > for NSSA-LSA :::0.0.0.0/96 When exporting external routes to NSSA areas, OSPF routers must have some global (preferably stub/loopback) addresses. > Followed by this, repeatedly, forever: > > Jul 11 18:21:15 router-priamry bird6: OSPF: Received non-hello packet from > unknown neighbor (src fe80::c67d:4fff:fe9f:945, iface em0) This is unrelated. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: ospf: how bird select best route
On Fri, Jul 11, 2014 at 08:53:32AM +0200, Piotr wrote: > router 1.1.1.5 it's server with bird > router 1.1.1.9 it's juniper with metric 70 > router 1.1.1.14 it's juniper with metric 30 > > network 1.1.1.0/28 > dr 1.1.1.9 > distance 10 > router 1.1.1.9 > router 1.1.1.5 This seems like NBMA related problem - perhaps 1.1.1.9 and 1.1.1.14 are not configured as neighbors to each other (not in BIRD but in their configurations). Therefore 1.1.1.9 does not include 1.1.1.14 as a neighbor in Net-LSA, and 1.1.1.14 is not reachable. When 1.1.1.9 is removed, another router (probably 1.1.1.14) is elected as DR and 1.1.1.14 became reachable. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: ospf: how bird select best route
On Fri, Jul 11, 2014 at 01:01:43AM +0200, Piotr wrote: > Hello, > > I advertise default gateway 0/0 from 2 juniper routers into servers with > bird. On one router (.14) advertise with metric 30 on second router > (.9) with metric 70. I see LSA from both routers but bird always select > metric 70 as better.. Beside metrics rest configuration are identical.. Interesting. Which BIRD version do you use? Could you send output of 'show ospf state'? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Infer BGP 'source address' value dynamically
On Tue, Jul 08, 2014 at 12:11:56PM -0700, Eric Cables wrote: > One last ping on this, to see if anyone has a BIRD specific solution / > example. Hi It is not possible in BIRD. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Implementation of default router preference in the radv protocol
On Mon, Jul 07, 2014 at 11:04:01PM +0900, Baptiste Jonglez wrote: > Hi, > > I just implemented default router preference (RFC 4191) in the radv > protocol. Patch follows. > > It's not a big change, but any feedback on the patch is welcome. Thanks, merged. I did just some trivial changes to the patch. https://gitlab.labs.nic.cz/labs/bird/commit/751482899c190194b4958bc54ded428f98f565e9 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BGP well known communities representation
On Thu, Jul 03, 2014 at 12:13:38PM +0300, MrBr @ GMail wrote: > In BIRD no-export and no-advertise communities visible in their numeric > form (65535, 65281) (65535, 65282). > Is there any way to represent them as no-export and no-advertise strings? No, but you could create a filter that will remove all other communities during route show. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: L2 MTU issues - is BFD proper solution?
On Thu, Jul 03, 2014 at 11:43:39AM +0200, Bartosz Radwan wrote: > We experienced recently several times issues caused by eg. EAPS path > swich in one of our L2 transmission providers (new path MTU was not big > enough due to jumbo frames not enabled - that's what they told us, but > in fact it does not meter - it's out of our control). > > From our point of view this situation sucks - we have several BGP > sessions, terminated on 2 different BGP routers in different data > centers, but problems as descripbed above in just one L2 provider > network may cause our all services are not fully operational - > especially when afeccted BGP sessions provides best routes for some > popular services like FB, YT or??? redtube.com ;). > > So, the question: is BFD able to detect broken L2 MTU and if detected - > disable affected BGP sessions? No. BFD sessions use very small packets, so they most likely do not notice problems specific to MTU. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Strange bgp_ext_community.add behaviour
On Thu, Jul 03, 2014 at 01:41:33PM +0300, Alexander Shikov wrote:
> Hi!
>
> On Thu, Jul 03, 2014 at 12:48:04PM +0200, Ondrej Zajicek wrote:
> > This is expected, as .add argument may be a (e)clist, but not a (E)C set,
> > and [ (ro,MyASN,10856), (ro,MyASN,3) ] expression is an EC set.
> Hm... Now I'm confused.
> "clist is similar to a set"
> I understand that as I can define eclist variable in a similar way:
> eclist var;
> var = [ ... ];
>
> I tried that:
> filter Reject_Static
> eclist cmn;
> {
> cmn = [ (ro,MyASN,10856), (ro,MyASN,3) ];
This is the same problem - assigning EC set value to eclist variable.
> "print cmn.len" does not print anything neither in syslog nor in stderr,
> when running with -d switch.
Seems like you have missing all log messages from filters. What your
'log' config option looks like?
> >From my point of view, expressions like
> bgp_community.add( [] )
> bgp_ext_community.add( [] )
> should treat arguments like (e)clist. It would be more logical.
Unfortunately with the way how the filter language is implemented,
expressions are interpreted independently of the context and the
'[...]' expression is just a set expression.
> > But it should report error during filter:
> > bird: filters, line 169: Can't add set
>
> It does not reports anything. Moreover, if change [] brackets with ()
> brackets:
> cmn = ( (ro,MyASN,10856), (ro,MyASN,2) );
> ... there is no syntax error, but it should be?
You can enclose any expression with () brackets, it does not change
its meaning, . It is like 2+2 vs (2+2).
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: Strange bgp_ext_community.add behaviour
On Thu, Jul 03, 2014 at 12:28:44PM +0300, Alexander Shikov wrote:
> Hello,
>
> I've met strange bgp_ext_community.add behaviour when adding ext. communities
> to static route:
>
>
> protocol static TEST {
> import filter {
> bgp_ext_community.add([ (ro,MyASN,10856), (ro,MyASN,3) ]);
> accept;
> };
> route 185.61.244.0/22 blackhole;
> }
> - does not work. Route is filtered:
> Jul 2 17:26:22 gate bird: TEST: State changed to down
> Jul 2 17:26:22 gate bird: TEST: Starting
> Jul 2 17:26:22 gate bird: TEST: Connected to table master
> Jul 2 17:26:22 gate bird: TEST: State changed to feed
> Jul 2 17:26:22 gate bird: TEST > filtered out 185.61.244.0/22 blackhole
>
> bgp_ext_community.add( [ (ro,MyASN,10856) ] );
> also don't work
>
> User's guide says that .add argument may be a (e)clist, thus this issue seems
> to be a bug.
>
> Please, advice! Thanks.
This is expected, as .add argument may be a (e)clist, but not a (E)C set,
and [ (ro,MyASN,10856), (ro,MyASN,3) ] expression is an EC set.
But it should report error during filter:
bird: filters, line 169: Can't add set
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: List of supported BGP extended communities
On Wed, Jul 02, 2014 at 06:09:05PM +0300, Alexander Shikov wrote: > Hi all, > > I'm not able to find full list of BGP ext. communities supported by bird. > In Users Guide there are only "route target/origin" mentioned. > Any other ext. community types are supported? Hi We support these 'type templates': RFC 4360 3.1. Two-Octet AS Specific Extended Community RFC 4360 3.2. IPv4 Address Specific Extended Community RFC 5668 4-Octet AS Specific BGP Extended Community These could have these subtypes: RFC 4360 4. Route Target Community RFC 4360 5. Route Origin Community (or any other subtype using 'unknown X' syntax) You could also construct any ext. community by: (generic, X, Y) But it is true that all of this is not well documented. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: incorrect memory usage reporting
On Sat, Jun 28, 2014 at 12:54:41PM +0200, Job Snijders wrote:
> Hi all,
>
> I use a BIRD instance for route collection from ~ 50 full bgp feeds [1]. The
> 'show mem' command reports very ambitious results:
>
> job@lg01:~$ sudo birdc show mem
> BIRD 1.4.2 ready.
> BIRD memory usage
> Routing tables: 4294967294 GB
> Route attributes: 1540 MB
> ROA tables:192 B
> Protocols: 311 kB
> Total: 0 GB
> job@lg01:~$ free -m
> total used free sharedbuffers cached
> Mem: 8759 4944 3815 0187366
> -/+ buffers/cache: 4390 4369
> Swap: 486 0486
> job@lg01:~$
>
> Might there be a counter that wraps around? How can I help debug this?
Hi
Does attached patch help?
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/lib/slab.c b/lib/slab.c
index e236e26..31529c3 100644
--- a/lib/slab.c
+++ b/lib/slab.c
@@ -123,7 +123,7 @@ static size_t
slab_memsize(resource *r)
{
slab *s = (slab *) r;
- int cnt = 0;
+ size_t cnt = 0;
struct sl_obj *o;
WALK_LIST(o, s->objs)
@@ -346,7 +346,7 @@ static size_t
slab_memsize(resource *r)
{
slab *s = (slab *) r;
- int heads = 0;
+ size_t heads = 0;
struct sl_head *h;
WALK_LIST(h, s->empty_heads)
signature.asc
Description: Digital signature
Re: Strange entries in OSPF LSADB
On Fri, Jun 27, 2014 at 12:10:11PM +0400, 1 ? wrote: > bird> show ospf lsadb > > 0001 10.0.0.010.0.0.0 174 811b43b4 > 0003 10.47.255.255 10.0.0.0 237 8001809e > 0003 10.48.0.0 10.0.0.0 68 800174a9 > 0003 10.79.255.255 10.0.0.0 62 8001feff > 0003 10.80.0.0 10.0.0.0 62 8001f20b > 0003 10.111.255.255 10.0.0.0 56 80017d61 > 0003 10.112.0.0 10.0.0.0 50 8001716c > 0003 10.143.255.255 10.0.0.0 44 8001fbc2 > 0003 10.144.0.0 10.0.0.0 44 8001efcd > 0003 10.175.255.255 10.0.0.0 38 80017a24 > 0003 10.176.0.0 10.0.0.0 32 80016e2f > 0003 10.207.255.255 10.0.0.0 26 8001f885 > 0003 10.208.0.0 10.0.0.0 20 8001ec90 > 0003 10.239.255.255 10.0.0.0 20 800177e6 > 0003 10.240.0.0 10.0.0.0 14 80016bf1 > > Is it normal? Yes, it is. LSA IDs could be any value from the network prefix and BIRD assigns them in a way that prevents collisions in the case that networks are nested. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Unnumbered interfaces and OSPF
On Thu, Jun 26, 2014 at 11:27:26AM +0200, Vincent Bernat wrote: > Hi! > > I am trying to use unnumbered interfaces and OSPF. Currently, you have to use peer addresses for unnumbered interfaces in OSPF: On one router: ip addr add 10.90.255.3 peer 10.90.255.4 dev eth0 On the other: ip addr add 10.90.255.4 peer 10.90.255.3 dev eth0 Although generally you could use the same pair on both interfaces, i don't know if i tested such case and if there are no hidden problems related to this. Also note that addresses of unnumbered interfaces are not propagated by default, So you would also need some regular or loopback/stub interface added to OSPF: ip addr add 10.90.255.3/32 dev lo -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Dynamic routes from OSPF disappear
On Thu, Jun 26, 2014 at 11:04:19AM +0200, Gregor Kališnik wrote: > On Thursday 26 of June 2014 11:27:08 Ondrej Zajicek wrote: > > On Wed, Jun 25, 2014 at 07:47:24PM +0200, Gregor Kališnik wrote: > > > Hi. > > > > > > I've checked and both agree on the same DR router (in bird checked the > > > show > > > ospf interface). > > > > Are you sure? According to BIRD output you sent, BIRD thinks that RouterOS > > (10.16.0.1) is DR, while RouterOS flushes its Net-LSA and does not originate > > another (which should be done by DR). > > Yes. Router said the DR is 10.16.0.1 (itself). I'll check what happens if > bird > is DR. > > If I look at the logs, router does send type 2 LSA (inside LSUPD packet), but > bird removes it. It does have age specified as 3600, tho. Sending LSA with age 3600 is a way how to flush LSA from OSPF domain. So it is RouterOS who flushed it for some reason. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Dynamic routes from OSPF disappear
On Wed, Jun 25, 2014 at 07:47:24PM +0200, Gregor Kališnik wrote: > Hi. > > I've checked and both agree on the same DR router (in bird checked the show > ospf interface). Are you sure? According to BIRD output you sent, BIRD thinks that RouterOS (10.16.0.1) is DR, while RouterOS flushes its Net-LSA and does not originate another (which should be done by DR). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: ipv4 inside ipv6 for ospf
On Mon, Jun 23, 2014 at 02:16:00PM +0400, Vasiliy Tolstov wrote: > Nice. Thanks! Last question - does bird developers have plans to fix > ecmp routing for ipv6? Definitely. The main question w.r.t. IPv6 ECMP in Linux is whether these fixes should be done to BIRD or to Linux kernel. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Behavior during OSPF premature aging
On Tue, Jun 24, 2014 at 08:46:20AM +0100, Lennard Klein wrote: > Hi, > > When premature aging an LSA, bird seems to increase the LSA sequence number > to its maximum (proto/ospf/lsupd.c line 616, in 1.4.3). > > While I think the main fault lies with the other vendor, my question > at this time is: what is the reasoning behind updating the sequence > number to its maximum, even though the RFC says to leave it as-is? Hi This is done mainly to compensate other problems/quirks/hacks in BIRD OSPF implementation. One reason is that if you flush LSA using MaxSeqNo, you could forget old LSA sequence number, and when you originate a new one later, you could safely start from InitSeqNo. Currently i am finishing OSPF revision that removes most of these BIRD quirks and problems related to LSA flood and makes BIRD much better in RFC compliance. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Dynamic routes from OSPF disappear
On Wed, Jun 25, 2014 at 04:40:52PM +0200, Gregor Kališnik wrote: > Hi. > > After some more investigation I've figured out that a LSA type 2 gets > removed. > After it is removed, all routes from OSPF are removed. By setting the > connection as ptp should fix it (link was broadcast before). > > Interface on the router has IP address 10.16.0.1/12 and on the server it has > 10.16.8.1/12. Server has a bridge (for LXC container) with 10.16.8.1/22. > > RouterOS' OSPF daemon is on 10.16.0.1/12 interface while bird is on > 10.16.8.1/12. As far as I know, this configuration should work as broadcast. Hi You could check whether both sides have the same idea of DR (designated router) and Backup DR. I have some reports about Mikrotik RouterOS vs. BIRD compatibility problems w.r.t. DR election, where both sides think the other side is DR. Workaround is to change network to PtP (if possible) or set different priority on both sided. BTW, RouterOS being the other OSPF router is the key information i missed in your original report. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: bird 1.4.3 ospfv3 issue on openbsd
On Wed, Jun 25, 2014 at 11:25:23AM +0200, Job Snijders wrote: > Hi all, > > I've upgraded up and down to see when the issue was introduced: between > 1.4.0 and 1.4.1. > > Ondrej, Martin, how can I help debug this? Would you like access to the > machines? Hi There were significant changes in socket code in this version, but most of them were related to IPv4. I tested it on OpenBSD 4.5 and some NetBSD and everything worked, but it is possible that with some combinations of OS versions, configurations and interface types there are problems, esp. on systems with small coverage likeh NetBSD and OpenBSD. Access to the machines would be the best. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: ipv4 inside ipv6 for ospf
On Mon, Jun 23, 2014 at 10:46:16AM +0200, Ondrej Filip wrote:
> On 23.6.2014 10:39, Vasiliy Tolstov wrote:
> > Hi. Does bird supports
> > http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-14
> > ?
> > If yes, how can i configure it?
>
> Hi Vasiliy,
> unfortunately it does not.
Hi
The draft (now published as RFC 6992) is just informational draft
specifying how to use existing features of OSPFv3 to do that and BIRD
already supports almost everything needed, so i would say it is
more or less supported.
You can just configure separate OSPFv3 instance (protocol block
in BIRD), use 'instance' parameter for all interfaces in that
OSPFv3 specifying chosen instance ID and use import and export
filters to filter out other prefixes than the one used for
IPv4-embedded IPv6 addresses.
There are some minor details:
1) RFC 6992 assumes that routers supports RFC 5838, which BIRD
does not, esp. it does not set AF-bit in Hello packets,
which means that it may fail to establish adjacency with other
implementations that implement RFC 5838.
2) BIRD does not support DN-bit (from RFC 4576, as requested by
RFC 6992 section 9), but that should not cause problems.
3) BIRD would also push local IPv6 prefixes to IPv4-embedded-IPv6
topology, which are not needed here. This may be limited by 'stubnet
::/0 { hidden };' option for stub networks, but prefixes related to
broadcast transit networks would still be added.
Alternatively, you could just use regular OSPFv3 instance for propagating
IPv4-embedded IPv6 prefixes together with regular IPv6 network topology.
This would make the setup simpler, as you would not need separate OSPFv3
instances and IPv6 routing tables. This is a bit different approach than
specified in RFC 6992, but it works in almost identically.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: Segmentation fault on EOR
On Sat, Jun 21, 2014 at 01:59:16AM +0400, Artyom Gavrichenkov wrote: > Hello Ondrej, > > 21.06.2014 01:15, Ondrej Zajicek ??: > >> In fact, this bug is not related to IPv6. It may appear even if bird > >> is used only for IPv4 routing, because multiprotocol extensions may be > >> also used in this case. > > > > Well, BIRD does not support IPv4 NLRI in multiprotocol extensions. > > This doesn't mean it may crash when the latter is sent to it, does it? No, regardless of this bug, they are just ignored as unknown route attributes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Segmentation fault on EOR
On Fri, Jun 20, 2014 at 08:32:29PM +0400, Evgeny Uskov wrote: > Hello, > > No, the bug I'm talking about was not fixed. It can be easily > reproduced on any of the versions 1.4.1, 1.4.2, 1.4.3 (by sending the > UPDATE message from my previous letter). You are right, i conflated two different bugs. This one is already fixed but only in git: https://gitlab.labs.nic.cz/labs/bird/commit/66370eac1f88ec74b3017f1c39038d7b8b776de6 > In fact, this bug is not related to IPv6. It may appear even if bird > is used only for IPv4 routing, because multiprotocol extensions may be > also used in this case. Well, BIRD does not support IPv4 NLRI in multiprotocol extensions. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Segmentation fault on EOR
On Fri, Jun 20, 2014 at 05:24:51PM +0400, Evgeny Uskov wrote: > Hello, > > bird with version >= 1.4.1 has the following bug: it falls with > segmentation fault when it receives certain BGP UPDATE messages. In > particular, the problem is triggered by a message with attributes but > without NLRI section. Hello This was fixed in 1.4.3: New release 1.4.3! Important bugfix in IPv6 BGP. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: about lo:0 interface
On Thu, Jun 19, 2014 at 05:24:45PM +0800, ?? wrote: > hi > > My system is Ubuntu 13.04, kernel version is 3.8.0-21-generic, bird version > is 1.3.10. > > I want to achieve lo: 0 (eg: 192.168.1.1/32) address as the route-id of the > device, while learning through ospf routing protocol ip address to manage > the device through this ip address. Hello First, I would generally suggest to use newer BIRD. Second, there is no such thing as lo:0, that is an illusion for legacy tools like ifconfig. IP addresses (esp. in case of multiple IP addresses on one interface) should be set by 'ip' tool in Linux. > Configured as follows: > > 1: I'm on a device configured lo:0 interface address: > > ifconfig lo:0 192.168.1.1/32 > > root @ sr1 :/ usr / local / bird # ifconfig lo:0 > lo: 0 Link encap: Local Loopback > inet addr: 192.168.1.1 Mask: 0.0.0.0 ^ Seems like the IP address was not set correctly, mask should be 255.255.255.255 . That is the source of your problems. > The problem is found in bird default route pointing to the interface, and > the interface address lo not found in the routing table, and why? Because the mask is 0.0.0.0, therefore prefix length is 0 and therefore directly attached network prefix is really 0.0.0.0/0, which is announced by Direct protocol. > bird> show interfaces > 1001-lo up (index = 1) > 1004 - MultiAccess AdminUp LinkUp Loopback Ignored MTU = 65536 > 1003 - 192.168.1.1 / 0 (Primary, scope univ) > 127.0.0.1 / 8 (Unselected, scope host) birdc in Ubuntu printed these message codes (100x)? They shouldn't be seen, that is probably some Ubuntu-specific bug. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: route attribute scope
On Fri, Jun 20, 2014 at 01:45:47PM +0200, Frederik Kriewitz wrote: > Hello, > > we noticed something which feels like an inconsistency/bug to us. > > So far we assumed that route attributes can be set in any filter of > any protocol. > But it seems like OSPF attributes can be set only in export filters of > OSPF protocols. Hello This is known inconsistency/quirk. It is is a result of current attribute implementation (where EAF_EMBEDDED attributes are stored directly in struct rte instead of in extended attribute list). Redesign of embedded attributes (to fix this problem and also to simplify it) is in my todo list. The current behavior is that regular attributes (e.g. ones from BGP) could be set anywhere, while embedded attributes (ones from OSPF, RIP and KRT) could be set either in export filter to 'their' protocol, or anywhere for 'their' routes (i.e. you could set ospf_metric1 anywhere for route received from OSPF, with source == RTS_OSPF, but that is probably not much useful). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: segfault error in bird6 after upgrading to 1.4.2
On Tue, Jun 17, 2014 at 05:53:18PM -0700, Paul Emmons wrote: > Just upgraded to 1.4.2 from 1.3.9 and having issue with a ipv6 session that > has 10k routes. Bird concierge as a route viewer ( no routing tables > exchanged) Try 1.4.3 : - New release 1.4.3! Important bugfix in IPv6 BGP. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] Maximum include depth in Bird config
On Tue, Jun 10, 2014 at 05:18:14AM +0400, Artyom Gavrichenkov wrote: > Hi all, > > The page at http://bird.network.cz/?get_doc&f=bird-3.html , section 3.2 > (as well as doc/bird.sgml), states that "the maximal depth [of > inclusion of a new file in a Bird config] is 5". However, effective > depth since July, 18, 2012, is 8 (9eceab33:conf/cf-lex.l:82). > > Maybe the user's guide needs an update, or depth 8 is unsupported? Yes, the guide needs an update. Thanks for the patch. BTW, i wonder how did you noticed that? Trying to have some deep include structure or just reading the source? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Modification to BIRD to support better anycast model
On Mon, Jun 09, 2014 at 03:50:40PM -0700, Jay Grizzard wrote: > Hi bird folks. > > My basic idea right now, in the spirit of "minimum workable footprint," > is to do something like having a route filter tied to a file on disk, > where the timestamp on that file is used to determine if the route > should be exported... if the file ages beyond a certain point, the route > gets filtered. > > My questions for the list, then: > - Am I correct that BIRD doesn't currently have any functionality of > this type available? I've gone through the manual a couple of times and > don't see anything obvious, but I could have missed something. Yes, you are correct, there is no such functionality. > - Assuming it can't, where would be the right place to implement this? > Is my guess about using an export filter a reasonable one? Anyone with > code familiarity care to comment on any gotchas I might run into while > doing this? No, export filter is not a reasonable place to have it. It is executed only when the route is propagated through it (and not later) and it should return the same value unless the route changed. IMHO best way to implement this would be in the static protocol as a modifier for a static route. The protocol could periodically check conditions for originating static routes and acts accordingly. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: preferred route statistics
On Fri, Jun 06, 2014 at 04:40:46PM +0200, Frederik Kriewitz wrote: > Hello, > > I noticed that the preferred route counter seems to be incremented for > each time the route is exported by another protocol. > E.g. I've a static protocol with 25 routes which are exported by two > other protocols, this results in the following statistics: I don't really understand your description. Routes for the same network imported from different protocols are considered separate and these stats should not depend on whether the route is exported to another protocols. > 25 imported, 0 exported, 50 preferred > > I'm wondering if that's the intended behavior? The intended behavior is that preferred counter counts the number of routes which are considered 'best' summed over all routing tables. I.e., if you have a protocol that propagates 25 routes to one table and these are then repropagated to a pipe to another three tables, and all these routes are best in all these tables, you get 100 preferred. If you have just one table, then preferred <= imported should be true. > So far I expected that preferred means number of routes which are > considered "best" in the corresponding routing table (so preferred > would be always <= imported). It is questionable whether directly attached table should be considered 'special' for this purpose. I don't see much reasons for this. It is possible that some routes are non-best in directly attached table but they are best in some other table. IMHO the most intuitive notion for 'preferred' would be to count the number of routes which are 'best' in any routing table, but that can't be easily computed with current internal structures. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] Add symbol support for various string options
On Tue, Jun 03, 2014 at 10:35:01AM +0200, Frederik Kriewitz wrote:
> Hello Ondrej,
>
> On Thu, May 29, 2014 at 11:13 PM, Ondrej Zajicek
> wrote:
> > Thanks, merged. Strictly speaking they should not accept symbols as
> > value, but string constants denoted by symbols.
>
> Thank you.
>
> I missed one option, in interface patterns string constants denoted by
> symbols aren't allowed yet.
> But it's a little more complicated.
>
> The relevant grammar:
> iface_patt_node_body:
>TEXT { this_ipn->pattern = $1; this_ipn->prefix = IPA_NONE;
> this_ipn->pxlen = 0; }
> | prefix_or_ipa { this_ipn->pattern = NULL; this_ipn->prefix =
> $1.addr; this_ipn->pxlen = $1.len; }
> | TEXT prefix_or_ipa { this_ipn->pattern = $1; this_ipn->prefix =
> $2.addr; this_ipn->pxlen = $2.len; }
>
>
> The last alternative "TEXT prefix_or_ipa" can be eaily converted to
> "text prefix_or_ipa". But simply changing the first alternative (just
> "TEXT") to "text" causes a conflict as both "text" and "prefix_or_ipa"
> might be a symbol.
Yes, i also noticed that. But it seems that whole prefix_or_ipa is a bit
problematic (you could use symbol for ipa but not for prefix, although
we support prefix constants) and it would need some further changes to
fix it. I will look at that.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
MRTdump (Was: Re: New in BIRD)
On Tue, May 27, 2014 at 08:42:04PM +0900, Ilias Pallikarakis wrote: > Hi, > I figured out that my problem was simply not configuring BIRD for > multihop neighbour. > I have, however, another question if someone would care to answer. From my > search so far I came to the conclusion that in BIRD you cannot mrtdump > to more > than one file (per process) and that it is still not possible to > periodically dump a > table. Is that correct ? Hello That is true. MRTdump was on border of my interests but it could be easily extended. What features w.r.t. MRTdump would be considered useful? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] Add symbol support for various string options
On Wed, May 28, 2014 at 04:43:31PM +0200, Frederik Kriewitz wrote: > Hello, > > during some bird config optimizations (redundancy reductions) we > noticed that various string options doesn't accept symbols as value. > Attached you find a patch which fixes that. Thanks, merged. Strictly speaking they should not accept symbols as value, but string constants denoted by symbols. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Stale Routes -- Long Uptime?
On Tue, May 20, 2014 at 07:08:14PM +, Stephen Holmes wrote: > Bird Users, > > BIRD version 1.2.5 > Uptime > 3 years, nice work guys! > > Two identical servers running BIRD with identical config. > > I ran into some routes sticking around in some of my route server > tables from a neighbor that was down. I did some testing and I had some > success reloading the pipe protocols, but not 100%. Even with that > neighbor and all it's pipes completely removed from the config the > routes remained, originating from the de-configured bgp peer. > > I am writing to see if others have had this experience with stale > routes. My version is really old, could this be a bug that has not > surfaced? Could the long uptime have lead to weirdness? Lastly, is > there a configuration issue that could lead to this? Hi This bug was fixed in 1.3.11 (and the crash is related to stale routes). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] Fix protocol memory use free under certrain configure/undo cases
On Mon, May 05, 2014 at 10:28:03AM +0300, Sergey Popovich wrote:
> It is possible to cause BIRD to use after free memory block, allocated
> to the protocol in the following conditions:
Hi
Thanks for the bugreport and the patch.
> diff --git a/nest/proto.c b/nest/proto.c
> index edb490f..c21be85 100644
> --- a/nest/proto.c
> +++ b/nest/proto.c
> @@ -599,7 +599,10 @@ proto_rethink_goal(struct proto *p)
>rem_node(&p->glob_node);
>mb_free(p);
>if (!nc)
> - return;
> +{
> + p->cf->global->proto = NULL;
I guess here should be p->cf->proto (there is no proto in p->cf->global).
It is probably better to move it unconditionally before
config_del_obstacle(), like in attached patch.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/nest/proto.c b/nest/proto.c
index 6278580..7a1e9bf 100644
--- a/nest/proto.c
+++ b/nest/proto.c
@@ -605,6 +605,7 @@ proto_rethink_goal(struct proto *p)
{
struct proto_config *nc = p->cf_new;
DBG("%s has shut down for reconfiguration\n", p->name);
+ p->cf->proto = NULL;
config_del_obstacle(p->cf->global);
rem_node(&p->n);
rem_node(&p->glob_node);
signature.asc
Description: Digital signature
Re: segfault with exabgp and bird 1.4.2
On Sat, May 03, 2014 at 09:19:22PM +0100, Charlie Allom wrote: > what do i win? :) A bugfix patch (attached) ;-) -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c index b623902..4464523 100644 --- a/proto/bgp/packets.c +++ b/proto/bgp/packets.c @@ -1112,7 +1112,7 @@ bgp_do_rx_update(struct bgp_conn *conn, if (conn->state != BS_ESTABLISHED) /* fatal error during decoding */ return; - if (a0 && ! bgp_set_next_hop(p, a0)) + if (a0 && nlri_len && !bgp_set_next_hop(p, a0)) a0 = NULL; last_id = 0;
Re: segfault with exabgp and bird 1.4.2
> On Sat, May 3, 2014 at 8:20 PM, Henrique de Moraes Holschuh > > If it managed to crash bird 1.4.2, bird is buggy regardless of whatever > > ExaBGP fed it. Exactly, it shouldn't crash for any input. On Sat, May 03, 2014 at 08:59:10PM +0100, Charlie Allom wrote: > fair enough, I will follow up with Ondrej with the coredump and binary > and pcap as I can replicate it :) Not needed. I already managed to replicate it with ExaBGP 3.2.19 . -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BGP/OSPF synchronisation
On Fri, May 02, 2014 at 02:32:12PM +1000, Tom Harbert wrote:
> Hello,
>
> I am running BIRD 1.4.2 on two Ubuntu Linux 12.04 systems acting as border
> routers. Two eBGP peers on each with iBGP between them. OSPF also between
> them and internally.
>
> I notice that on reboot 10-15 packets both in and out are lost. This seems
> to happen just as/after the bird process starts. It appears as if perhaps
> BGP is establishing prior to the OSPF neighbors coming up and as a result
> black-holing traffic. I am nailing down my public IP prefixes with null
> routes.
You mean that eBGP sessions established first? I guess there is no such
problem with iBGP sessions, as these usually depend on routable IP
addresses of neighbors, so they cannot establish before OSPF converges.
But singe-hop eBGP sessions could be established fast.
> I have attempted to use the 'start delay time x' command under the BGP
> sessions however they still establish immediately. I believe this is
> because this command delays the outbound attempt to connect yet the remote
> side is initiating it.
Yes, that is true, 'start delay time x' governs just outbound attempts.
> # eBGP session to X
> protocol bgp eBGP_X {
> description "eBGP - X";
> local as X;
> neighbor x.x.x.x as x;
> * start delay time 60;*
> import filter import_eBGP_X;
> export filter export_eBGP_X;
> }
>
> Has anyone else ran into this problem with a similar design? Is there a
> different command to prevent BGP peering from establishing or to wait for
> the IGP?
Currently, there is no feature allowing postponed start of some
protocols. I am interested in receiving suggestions or proposals on how
such dependence between protocols should behave or how it behaves in
other implementations.
> I have implemented a workaround/hack by filtering incoming TCP connections
> with destination port 179. This prevents the peers from being established
> until the *start delay time* is reached. I will review my routing
> configuration/design however is there another way to accomplish this?
One workaround would be to start BIRD with disabled BGP protocols and then
use 'birdc enable bgpX' to start them, but that would have another
problem - any reconfiguration would disable them back.
Another workaround would be to use another BIRD just to announce your
public IP prefixes to your border routers by iBGP. Therefore a restarted
border router would not announce anything until it connects to this one
using iBGP which naturally depends on convergence of OSPF in internal
network.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: segfault with exabgp and bird 1.4.2
On Sat, May 03, 2014 at 05:42:24PM +0200, Ondrej Zajicek wrote: > On Sat, May 03, 2014 at 02:37:18PM +0100, Charlie Allom wrote: > > Hi, > > > > I have been running a stable mesh with a BIRD peer in a mesh for a few > > weeks now. > > > > Trying to connect with ExaBGP makes BIRD segfault. How can I debug this > > further? > > Could you send me core dump and your ExaBGP config? And your ExaBGP version. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: segfault with exabgp and bird 1.4.2
On Sat, May 03, 2014 at 02:37:18PM +0100, Charlie Allom wrote: > Hi, > > I have been running a stable mesh with a BIRD peer in a mesh for a few > weeks now. > > Trying to connect with ExaBGP makes BIRD segfault. How can I debug this > further? Could you send me core dump and your ExaBGP config? You could also try 1.4.3 (1.4.2 has known bug, but this seems like some different problem). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BIRD 1.4.2 - some strange things
On Wed, Apr 23, 2014 at 04:31:50PM +0300, Javor Kliachev wrote: > Hello, > > After upgrade from 1.3.9 to 1.4.2, we're observing following things: > > *1) Testing ADD-PATH feature on iBGP:** > * > With AS-PATH functionality everything looks fine but: > > How we may see all exported routes to given iBGP member with "add paths > on" enabled. > > I have tried with: > > root@rs2-nix-bird:~# birdc show route export R0_100 count > *2796* of 3377 routes for 3377 networks Yes, 'show route export' shows bad information here, it ignores the fact that 'add paths' is enabled. BIRD does not store information whether the route was exported to the protocol, it just computes whether it would be exported during 'show route export', so it may show different information because of bugs or reconfiguring. > *So my question is*: Is there any other command to see all exported > prefixes when as-path is enabled. Not really, but 'show route export' should be fixed. You could just use 'show route where proto != "R0_100"' if you have 'export all' or something similar. > *2) BGP Route limit - strange thing:* > > With the new version, today I observed that when "BGP protocol" has > configured limit to 1, every time > when we run "birdc configure" the session from UP goes DOWN and back to > UP and then stay ESTABLISHED > with following reason: > > It is happen absolutely everytime when we run "birdc configure". Seems like when route is received, the limit is perceived as less or equal, while during reconfigure it is perceived as strictly less. The documentation is not unambiguous w.r.t. this issue, but i would guess that understanding limits as less or equal is probably what users expect. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: [PATCH] More multipath support for OSPF
gw, struct iface
> *iface, unsigned cha
> }
>
> static inline struct mpnh *
> -copy_nexthop(struct proto_ospf *po, struct mpnh *src)
> +copy_nexthop(struct proto_ospf *po, const struct mpnh *src)
> {
>struct mpnh *nh = lp_alloc(po->nhpool, sizeof(struct mpnh));
>nh->gw = src->gw;
> @@ -64,74 +66,153 @@ copy_nexthop(struct proto_ospf *po, struct mpnh *src)
>return nh;
> }
>
> +static void
> +add_nexthops(struct proto_ospf *po, struct orta *old, const struct orta *new)
> +{
> + struct mpnh **pnh = &old->nhs;
> + struct mpnh *newnh = new->nhs;
> +
> + int count = po->ecmp;
> +
> + /* Iterate through new next hops */
> + while (newnh != NULL && count)
> + {
> +struct mpnh *nh = *pnh;
> +if (nh == NULL)
> +{
> + /* Add next hop to end of list */
> + *pnh = nh = copy_nexthop(po, newnh);
> +
> + pnh = &nh->next;
> + newnh = newnh->next;
> +}
> +else
> +{
> + int cmp = cmp_nhs(nh, newnh);
> + if (cmp < 0)
> + {
> + /* Continue to next nexthop */
> + pnh = &nh->next;
> + }
> + else if (cmp > 0)
> + {
> + /* Add nexthop before current nexthop */
> + struct mpnh *next;
> +
> + *pnh = next = copy_nexthop(po, newnh);
> +
> + next->next = nh;
I think this code is wrong, because orta.nhs values are shared between
different orta nodes created from one top_hash_entry (like one
router-LSA with several stub networks), therefore old->nhs cannot be
modified in place. Proper solution would be use the similar approach
like in merge_nexthops() - check if orta.nhs is private or shared and
merge accordingly. I modified the code of merge_nexthops() so it
could be used for both top_hash_entry.nhs and orta.nhs merging, as it is
essentially the same process.
> /* Whether the ASBR or the forward address destination is preferred
> in AS external route selection according to 16.4.1. */
> static inline int
> -epath_preferred(orta *ep)
> +epath_preferred(const orta *ep)
> {
>return (ep->type == RTS_OSPF) && (ep->oa->areaid != 0);
> }
>
> -/* 16.4. (3), return 1 if new is better */
>
> - /* 16.4. (6c) */
> + /* 16.4. (6c) - If not RFC1583, select preferred paths */
>if (!po->rfc1583)
>{
> -u32 new_pref = new->options & ORTA_PREF;
> -u32 old_pref = old->options & ORTA_PREF;
> -
> -if (new_pref > old_pref)
> - return 1;
> -
> -if (new_pref < old_pref)
> - return 0;
> +ret = (new->options & ORTA_PREF) - (old->options & ORTA_PREF);
> +if (ret != 0)
> + return ret;
I think here is a bug, because ORTA_PREF is 0x8000, which means that
if new has the flag while old does not, ret would be negative (because
0x8000 typecasted to int is -2^31).
>
> - /* 16.4. (6d) */
> - if (new->metric1 < old->metric1)
> -return 1;
> -
> - if (new->metric1 > old->metric1)
> -return 0;
> -
> - /* RFC 3103, 2.5. (6e) */
> - int new_prio = orta_prio(new);
> - int old_prio = orta_prio(old);
> + /* 16.4. (6d) - Prefer the route with lowest type 1 metric */
> + ret = old->metric1 - new->metric1;
> + if (ret != 0)
> +return ret;
>
> + /* RFC 3101, 2.5. (6e) - Prioritize Type-7 LSA with P-bit, then Type-5
> LSA, then LSA with higher router ID */
> + ret = orta_prio(new) - orta_prio(old);
> + if (ret != 0)
> +return ret;
>
> - /* make it more deterministic */
> - if (new->rid > old->rid)
> -return 1;
> + /* RFC 3101, 2.4 (2) - If the P-bit settings are the same, the LSA with
> higher router ID is preferred */
> + if (new->options & ORTA_NSSA)
> + {
> +ret = (new->rid > old->rid) - (new->rid < old->rid);
> +if (ret != 0)
> + return ret;
> + }
>
> - return 0;
> + /* Prefer largest area id */
> + ret = (new->oa->areaid > old->oa->areaid) - (new->oa->areaid <
> old->oa->areaid);
> + return ret;
> }
These two comparisons (RFC 3101 2.5 (6e) preferences and largest area
ID) do not make sense for external routes. The first one (together with
higher router ID preference) is intended primarily for functionally
equivalent LSAs (i.e. same non-zero forwarding address and other
fields). There is no reason to not merge them (but we have to keep best
LSA according to this criteria in orta.en for proper NSSA translation
mechanism).
There is no reason to compare area IDs for external routes (and such
comparison is not mentioned in RFC 2328). Altough BIRD keeps orta.oa for
external rtes, are
Re: question : broadcast kernel table via OSPF
On Sat, Apr 19, 2014 at 10:28:02AM +0800, b...@indoakses-online.com wrote:
> Dear All.
>
> I really appreciate your help
>
> >>
> >> I change it to :
> >>
> >> export filter {
> >> ospf_metric1 = 1000;
> >> accept;
> >> };
> >
> > Yes that.
>
> 1. New Configuration is at : http://pastebin.com/zFW8Uw5g
That is OK.
> > You could check the router-A BIRD routing table by 'show route' whether
> > the routes were imported to BIRD.
>
> 2. from birdc4 show route, I still only got :
> bird> show route
> 10.0.0.0/24dev bat0 [ospf1 09:08:54] * I (150/1000) [10.0.0.2]
> 172.16.3.0/24 via 10.0.0.3 on bat0 [static1 09:08:45] * (200)
>
> While it's kernel routing table is :
> root@owrt-bino:~# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 10.0.0.0* 255.255.255.0 U 0 00 bat0
> 172.16.1.0 * 255.255.255.0 U 0 00
> br-lan
> 172.16.3.0 10.0.0.3255.255.255.0 UG0 00 bat0
> 192.168.10.0* 255.255.255.0 U 0 00 eth0
>
> Looks like that 172.16.1.0/24 route is not imported
Yes. You should check your routes using 'ip route show' to see route
source values. Older (pre-1.4.x) versions of BIRD did not import kernel
device routes, so if you have pre-1.4.x BIRD and Batman daemon does not
use proper source value and uses RTPROT_BOOT value instead, then these
are not imported.
> > You could check logs if they do not contain warnings.
> >
> 3. Where is the Bird4 log file ?
According to your bird.conf you use logging to syslog so it depends on
your syslog config.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: question : broadcast kernel table via OSPF
On Thu, Apr 17, 2014 at 06:59:02PM +0800, b...@indoakses-online.com wrote:
> >> My question is : Why Kernel route table of Router-A is NOT broadcasted ?
> >
> > Because you have this in your export filter:
> >
> > if source = RTS_STATIC then accept; else reject;
> >
> > Which rejects other than static routes. Just replace it with 'accept;'
>
> What do you mean with "Just replace it with 'accept'" ?
>
> I change it to :
>
> export filter {
> ospf_metric1 = 1000;
> accept;
> };
Yes that.
> And still didn't work.
You could check the router-A BIRD routing table by 'show route' whether
the routes were imported to BIRD.
You could check logs if they do not contain warnings.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: question : broadcast kernel table via OSPF
On Thu, Apr 17, 2014 at 05:23:12PM +0800, b...@indoakses-online.com wrote: > Dear all > > I'm trying to learn BIRD4 to do ospf over batman-adv > got to router : > 1. router A > 1.a. OSPF is at interface 'bat0' > 1.b. Have 172.16.1.1/24 address at another interface, and have 'external > route' > 1.c. bird4.conf is at : http://pastebin.com/kin9MEnw > 1.d. have birdc4 installed > > 2. router B > 1.a. OSPF is at interface 'bat0' > 1.b. bird4.conf is at : http://pastebin.com/XGTuHqfr > 1.c. Not enough space to have birdc4 onboard You could have birdcl4 (light client) here. But perhaps i would have to update OpenWrt packaging scripts to include it. > - > Looks like : > B.1. External route defined at Router-A is broadcasted ... nice > B.2. Kernel route table of Router-A is NOT broadcasted. > > My question is : Why Kernel route table of Router-A is NOT broadcasted ? Because you have this in your export filter: if source = RTS_STATIC then accept; else reject; Which rejects other than static routes. Just replace it with 'accept;' You should see other routes in 'show ospf state' as external. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Version 1.4.3
On Tue, Apr 15, 2014 at 09:12:26AM +0200, Ondrej Filip wrote: > On 14.4.2014 23:23, Pierluigi Rolando wrote: > > Hi, > > I see that the second commit > (https://gitlab.labs.nic.cz/labs/bird/commit/7c4a8007255403d046d7e909f710f0b1ed1791b1) > applies to 1.4.0 and possibly earlier. Is that function truly unused? At > a first glance it occurs a few times in the code. > > Hi! > Where do you see it being used? Hi The function is used, but only in rmemsize() / cmd_show_memory(), so it just reports few bytes less memory than it should, nothing serious. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BFD on 1.4.2
On Mon, Apr 14, 2014 at 05:12:31PM +0200, Kristoffer Egefelt wrote: > Hi, > > I?m trying BFD with some Force10 S4810 routers, problem is that sessions only > come up every 3 or 4 times I restart bird. > Also if Force10 routers are restarted, some times the sessions do not come > back up. > Also I have to restart bird to get it to work - birdc configure does not do > it. > > I tried with the sysctl -w net.ipv4.ip_local_port_range="49152 65535? but > this does not help either. > > I?m not able to get more debug info from the force10 devices than this: What you get from 'show bfd sessions' in BIRD? Could you get some tcpdump of BFD packets in both cases? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: IPv6 BGP debugging
On Fri, Apr 11, 2014 at 07:03:21PM +0400, Alexander V. Chernikov wrote: >> Hmm, that seems like sime kind of strange coincidence, as the rta *a variable >> is not used before it is initialized (see attached patch). > > Well, not exactly. DECODE_PREFIX() can perform 'goto done' for invalid > prefix being withdrawn. In that case we'll probably get garbage in a. > > Anyway, initially I was talking about IPv6 case (which has different > bgp_do_rx_update() version). > The same there, DO_NLRI() can jump to 'done' label before *a > initialization which actually happened. > > I suddenly realized that we're speaking about different crash cases: the > one I'm talking about is much clearer: .. > DO_NLRI(mp_reach) is not used so "a" assignment does not happen. You are right, in both cases. Thanks for debugging it. These are stupid mistakes. Seems like 1.4.1 was really not a lucky release. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: received-routes command
On Thu, Apr 10, 2014 at 11:40:04PM +0800, Jimmy Halim wrote: > Hi guys, > > I am sorry if I am bringing this question again since I have been away from > BIRD community for awhile. Can we show BGP ?received-routes? command in BIRD > right now? I understand the latest release is v1.4.2. Hello You could enable 'import keep filtered' option for a protocol and then use 'show route filtered' to see rejected routes, while 'show route' would show accepted routes. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: IPv6 BGP debugging
On Thu, Apr 10, 2014 at 09:44:57PM +0400, Alexander V. Chernikov wrote:
> On 10.04.2014 12:41, Ondrej Zajicek wrote:
>> On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
>>> Hi Alexander,
>>>
>>> I tried "debug MLPA1 all" from birdc console, but nothing new appeared in
>>> log file.
>>>
>>> Currently I rolled back to 1.3.10 version from ports because 1.4.2 started
>>> to crash with the following backtrace:
>> Do you have the same socket problems in 1.3.10 or not?
>>
> We're currently investigating this further, it really looks like
> OS-dependent problem.
> However, it seems that core was triggered by uninitialized rta *a in
> IPv6 bgp_do_rx_update().
Hmm, that seems like sime kind of strange coincidence, as the rta *a variable
is not used before it is initialized (see attached patch).
Perhaps it is related to the bug fixed in
efd6d12b975441c7e1875a59dd9e0f3db7e958cb ?
Are these compiler options used in FreeBSD build?
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
--- /home/santiago/work/devel/bird/DEV/bird/proto/bgp/packets.c 2014-03-24 19:08:57.0 +0100
+++ packets.c 2014-04-10 21:36:14.0 +0200
@@ -1082,7 +1082,7 @@
{
struct bgp_proto *p = conn->bgp;
struct rte_src *src = p->p.main_source;
- rta *a0, *a;
+ rta *a0;
ip_addr prefix;
int pxlen, err = 0;
u32 path_id = 0;
@@ -1115,6 +1115,7 @@
if (a0 && ! bgp_set_next_hop(p, a0))
a0 = NULL;
+ rta *a;
a = NULL;
last_id = 0;
src = p->p.main_source;
signature.asc
Description: Digital signature
Re: IPv6 BGP debugging
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote: > Hi Alexander, > > I tried "debug MLPA1 all" from birdc console, but nothing new appeared in > log file. > > Currently I rolled back to 1.3.10 version from ports because 1.4.2 started > to crash with the following backtrace: Do you have the same socket problems in 1.3.10 or not? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: bgp route selection
On Tue, Apr 08, 2014 at 07:11:36PM +0200, Frederik Kriewitz wrote:
> On Tue, Apr 8, 2014 at 5:50 PM, Thomas Goldberg
> wrote:
> > Is there any other solution for this besides doubling the iBGP
> > connections (adding seperate blackhole only sessions with higher
> > preference)?
>
> We faced the same problem in the past.
> The preference can be set on a per route basis during the import.
> If you add the following line to your import filter it should do the
> trick for you:
> preference = bgp_local_pref;
> That way the bgp local preference is used as the bird internal preference too.
That will work, but in this case i would prefer an alternative: do not
depend on recursive resolution of bgp_next_hop to blackhole route, but
set blackhole destination directly in filters:
if bgp_next_hop = A.B.C.D then {
dest = RTD_BLACKHOLE;
}
In that case recursive resolution of next hop is not used and
resolvability test does not apply.
> Having read only the mentioned section of RFC 4271 someone might argue
> that bird should consider blackhole routes as resolvable too:
>
> ...
>
> That's how it's implemented on our alcatel/cisco/juniper routers too,
> bird seems to be the exception here.
Well, it is debatable whether IP covered by unreachable/blackhole/prohibit
routes should be considered resolvable for these purposes. I would say
that semantically such addresses are more-or-less equivalent to
addresses not covered by any routes.
> Overall I'm a little confused about the implementation now too. If the
> next hop is not resolvable it shouldn't be concidered at all but bird
> apparently still considers blackhole routes as a last resort or with
> higher bird preference.
That is true, BIRD currently cannot completely suppress a route based on
unreachability of the nexthop, it just make unresolvable route
a lowest priority route in its preference group.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: IPv6 BGP debugging
On Wed, Apr 09, 2014 at 01:36:31PM +0400, Peter Andreev wrote: > Hi everybody, > > I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following: > > PTTlgBGP master start 13:10:24Connect Socket: Invalid > argument > MLPA1BGP master start 13:10:24Connect Socket: > Operation timed out > MLPA2BGP master start 13:10:24Connect Socket: Invalid > argument > > All these BGP protocols are inherited from one template. The only > difference is that those are established, use another source address which > is configured on virtual interface. > > However my question is how to find out what's going on and how to detect a > problem? Setting "log syslog all;" is not very helpful - it only fills the > log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to > kernel: No such process" messages. Hi Socket errors are usually errors reported by OS kernel related to TCP (for BGP) socket, so there is not much to debug in BIRD. You could add 'debug all' to that BGP protocols, but i would guess these errors are just reactions to connect() syscall. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: bgp route selection
On Mon, Apr 07, 2014 at 05:28:24PM +0200, Thomas Goldberg wrote: > Hello, > > can yomeone please explain me the following behaviour: > There's one eBGP session (b_dtag1) and one iBGP session with one of > our RR Servers (b_rr1). > The RR redistributes the blackhole prefixes learned from the Spamhouse > BGP Feed (BGPf). > > The prefix 64.112.128.0/18 is supposed to be blackholed. > > These are the two routes learned from the two peers: > bird> show route all 64.112.128.0/18 > 64.112.128.0/18via X.X.X.X on eth0 [b_dtag1 Apr06] * (100) [AS3320i] > ... >blackhole [b_rr1 15:36 from Y.Y.Y.Y] (100/-) [AS65535i] > ... > > As you can see the (older) regular eBGP route is picked over the > blackhole route: > > Based on the Route selection rules from > http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 I expected that > the first (Prefer route with the highest Local Preference attribute) > and the second (Prefer route with the shortest AS path) rule would > result in the blackhole route being picked. Hello That is because only resolvable routes are considered (RFC 4271 9.1.2.1), main reason for that condition is to eliminate routes whose bgp_next_hop cannot be resolved using IGP, it also affects routes whose bgp_next_hop is resolved to a unreachable/blackhole/prohibit route. In your case, it could be fixed by adding higher protocol preference (different attribute than bgp_local_pref, currently 100) to b_rr1. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: ipv6 ecmp ospf
On Sun, Apr 06, 2014 at 03:19:26PM +0400, Vasiliy Tolstov wrote: > Hi all. I'm try to get working ecmp with ipv6 and bird 1.4. > Now i'm not understand why routes to test ip installed and removed > after 3-5 seconds. Can somebody helps me? Short answer: They are not supported. Long answer: Well, BIRD generates IPv6 ECMP routes for internal tables and tries to export them to kernel tables in the same way as IPv4 ECMP routes, but Linux kernel did not support these for a long time. In some recent kernel version. they were implemented, but with a different API/conceptual model than IPv4 routes and with some lame compatibility layer, which works for some operations (route insert) but not for others (route scan), so it is broken. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: BGP TTL Hack and BIRD
On Fri, Apr 04, 2014 at 09:45:53AM -0700, Kris Pederson wrote: > Hi, > > Does BIRD support the "TTL Hack"? If so, please advise on configuration > recommendations. Thanks! Yes, see 'ttl security' option. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
Re: Cnange next-hop
On Fri, Apr 04, 2014 at 06:19:28PM +0300, Alexander Shikov wrote:
> Hi,
>
> continuing the implemetation of blackhole in our IXP, I've faced with problem
> of
> changing next-hop for the route.
>
> Construction looks like
>
> if (net.len = 32 && bgp_community ~ [ (31210,*) ] && bgp_community ~ [
> (0,666) ] ) then {
> gw = 193.25.181.253;
> return true;
> }
>
> results in :
>
> bird> show route for 95.67.13.2/32 all
> 95.67.13.2/32 via 193.25.181.253 on bge0 [COSMONOVA2 2014-04-04 17:59:19
> from 193.25.180.133] * (50) [AS34867i]
> Type: BGP unicast univ
> BGP.origin: IGP
> BGP.as_path: 34867
> BGP.next_hop: 193.25.180.133
> BGP.local_pref: 100
> BGP.community: (0,666) (31210,31210)
>
>
> And when this route is announced to other peer, next-hop remains unchanged:
>
> Peerings.inet.0: 16708 destinations, 50556 routes (16627 active, 0 holddown,
> 88 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 95.67.13.2/32 *[BGP/170] 00:12:14, localpref 100, from 193.25.180.255
> AS path: 34867 I
> > to 193.25.180.133 via xe-1/0/0.777
>
> As far as I understand from User's Guide, gw is an read-write attribute,
> so why it didn't change next-hop?
Because gw and bgp_next_hop are related but separate attributes. You
have to change bgp_next_hop.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
Re: BIRD 1.4.2 compile fails with debug option
On Fri, Apr 04, 2014 at 05:04:22AM +, Bahram BahramBeigy wrote:
> Hi,
> When I want to compile BIRD with --enable-debug option, it fails with the
> following error. while without the debug option it compiles fine.
This should fix it.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/nest/proto.c b/nest/proto.c
index 13a0833..fc674ed 100644
--- a/nest/proto.c
+++ b/nest/proto.c
@@ -1235,7 +1235,7 @@ proto_want_core_up(struct proto *p)
static void
proto_want_export_up(struct proto *p)
{
- ASSERT(p->core_state == CS_HAPPY);
+ ASSERT(p->core_state == FS_HAPPY);
ASSERT(p->export_state == ES_DOWN);
proto_link_ahooks(p);
@@ -1258,7 +1258,7 @@ proto_want_export_down(struct proto *p)
static void
proto_want_core_down(struct proto *p)
{
- ASSERT(p->core_state == CS_HAPPY);
+ ASSERT(p->core_state == FS_HAPPY);
ASSERT(p->export_state == ES_DOWN);
p->core_state = FS_FLUSHING;
signature.asc
Description: Digital signature
Re: BFD implementation in 1.4.0
On Wed, Apr 02, 2014 at 05:19:06PM +0400, Mikhail A. Grishin wrote: > Ondrej Zajicek wrote, 01.04.2014 20:06: >> On Wed, Mar 26, 2014 at 05:09:25PM +0400, Mikhail A. Grishin wrote: >>> 1) How we can view via birdc the state of BFD-enabled peer in terms of >>> BFD state (up/down) ? >> >> bird> show bfd sessions >> bfd1: >> IP addressInterface State Since Interval Timeout >> 10.0.0.23 eth0 Up 2014-03-310.2000.600 > > Please add "show bfd" to context menu: Thanks, i missed that. >>> 2) When BFD with some BGP peer is in Up state, how BFD-related >>> parameters for that peer can be viewed via birdc? >>> Examples for similar outputs from Cisco&Juniper - in attach. >> >> Currently not available, but 'show bfd sessions' shows almost all >> relevant info anyways. > OK, thanks. Any plans to improve? Probably. >>> 4) (Minor) >>> "bird> show protocols all bfd1" shows some Routes counters. Does that >>> make sense? >> >> Well, no. Note that it also does not make sense for 'device' protocol, >> but nobody ever complained about that. ;-) > > kernel and direct protocols output doesn't show Routes counters :) Yes if they are up: bird> show protocols all name prototablestate since info device1 Device master up 13:08:02 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filteredignored accepted Import updates: 0 0 0 0 0 Import withdraws:0 0--- 0 0 Export updates: 0 0 0--- 0 Export withdraws:0--------- 0 direct1 Direct master up 13:08:02 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 5 imported, 0 exported, 5 preferred Route change stats: received rejected filteredignored accepted Import updates: 5 0 0 0 5 Import withdraws:0 0--- 0 0 Export updates: 0 0 0--- 0 Export withdraws:0--------- 0 kernel1 Kernel master up 13:08:02 Preference: 10 Input filter: ACCEPT Output filter: (unnamed) Routes: 0 imported, 8 exported, 0 preferred Route change stats: received rejected filteredignored accepted Import updates: 0 0 0 0 0 Import withdraws:0 0--- 0 0 Export updates: 20 10 0--- 10 Export withdraws:2--------- 2 bfd1 BFD master up 13:08:02 Preference: 0 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filteredignored accepted Import updates: 0 0 0 0 0 Import withdraws:0 0--- 0 0 Export updates: 0 0 0--- 0 Export withdraws:0--------- 0 -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." signature.asc Description: Digital signature
