gmane.network.bird.user

Re: Propagating /32 from OSPF to BGP

Ondrej Zajicek — 2013-06-19T11:32:04

Hi

The main question is whether there is any reason why ISP should prefer
these routers from GW_1 or from GW_2. Unless you do some attribute
modification in export filters then IMHO there is no such reason - IGP
metric is not propagated through eBGP and therefore ISP receives two
more or less equivalent routes for the same prefix. It is strange that
it chooses different GW for x.x.74.112/31 and for x.x.74.114/32 - when
routes are the same, ISP should consistently choose one received from
the router with smaller router ID, but it could be configured to use RFC
5004 behavior and prefer the older one, which would be nondeterministic.

The solution would be to propagate IGP metric as BGP MED attribute
(and ensure that ISP do not ignore this attribute). If you are sure
that ospf_metric2 is the same, you could do that simply by using 
'bgp_med = ospf_metric1;' for routes from OSPF in BGP export filters.

Also, the best info would be to see these routes (with their BGP attributes)
on ISP router.

Re: Propagating /32 from OSPF to BGP

Simon Dickhoven — 2013-06-19T01:08:49

A more detailed topology (with IPs and interface names) would be helpful 
to understand the setup better.

Is it possible that your ISP is accepting "le 32" on their BGP session 
with GW_2 (and that's the one they checked when you asked them to 
verify) but only "le 31" on their BGP session with GW_1?

I have certainly run into this problem before: Asked the ISP to verify. 
They did and said that all is good on their end. But when I finally 
asked them to send me their configs it turned out that they had screwed 
something up.

One thing I noticed is that GW_1 shows interface "tunVpnCust" for OSPF 
and "ifDmz1" for BGP whereas GW_2 shows interface "tunO2Oorc4" for both. 
Since I don't have a more detailed topology that explains where 
172.31.253.1 and 172.31.253.32 are and what the respective interfaces 
connect to it's difficult to guess what's going on.

But double-checking with your ISP and possibly asking them for their 
configs is one thing you could do to rule out the possibility that the 
problem is on their end.

Sorry I couldn't be more helpful.

- Simon

On 06/18/2013 05:46 PM, Michael Ludvig wrote:

Re: RIPng advertisement hop count 1 (should be 255 per RFC)

Simon Dickhoven — 2013-06-19T00:48:29

Correction: The RFC does state explicitly that advertisements must be sent with an HLIM of 255, as well as that receiving routers must check that the HLIM is 255.

So I guess my little patch makes BIRD half-compliant in that respect then :).

- Simon

On Jun 18, 2013, at 17:38, "Simon Dickhoven" <Simon.Dickhoven< at >tachyon.com> wrote:

Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Propagating /32 from OSPF to BGP

Michael Ludvig — 2013-06-19T00:46:04

Hi

we've got a private AS with two uplinks to our ISP, and we've got a
number of subnets that we advertise. Now we got a new assignment and it
doesn't work as expected.

Here is the situation:

x.x.74.113
x.x.74.114
[DMZ1_box_1]
    ||
[DMZ1_GW] -- OSPF -- [GW_1] -- OSPF -- [GW_2] -- OSPF -- ...
x.x.24.227
                        |                 |
                       BGP               BGP
                        |                 |
                     ISP_rtr_1        ISP_rtr_2
                          \           /
                         ISP & Internet

Now if I advertise the new subnet /29 (or up to /31) from DMZ1_GW it
gets propagated to both BGPs and the ISP correctly routes the traffic to
GW_1 as it's closer to the box.

However if I advertise the IP/32 from DMZ1_GW then for some reason the
traffic is routed from Internet to GW_2 first. ISP confirmed they accept
up to /32 from us.

This is the relevant output from GW_1:
GW_1 ~ # birdc show route protocol ospf_eit | grep ^x.x.74
BIRD 1.3.8 ready.
x.x.74.114/32 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2
(150/1/10000) [x.x.24.227]
x.x.74.112/31 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2
(150/1/10000) [x.x.24.227]

GW_1 ~ # birdc show route export bgp_isp | grep ^x.x.74
BIRD 1.3.8 ready.
x.x.74.114/32 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2
(150/1/10000) [x.x.24.227]
x.x.74.112/31 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2
(150/1/10000) [x.x.24.227]


This is the relevant output from GW_2:
GW_2 ~ # birdc show route protocol ospf_eit| grep ^x.x.74
BIRD 1.3.8 ready.
x.x.74.114/32 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2
(150/11/10000) [x.x.24.227]
x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2
(150/11/10000) [x.x.24.227]

GW_2 ~ # birdc show route export bgp_isp | grep ^x.x.74
BIRD 1.3.8 ready.
x.x.74.114/32 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2
(150/11/10000) [x.x.24.227]
x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2
(150/11/10000) [x.x.24.227]

As it is now a ping from outside to x.x.74.113 (that's advertised as
/31) goes to GW_1, which is correct and a ping to x.x.74.114 (that's
advertised as /32) goes to GW_2, that's incorrect.

How come? I can't see what am I doing wrong...?

Any ideas?

Thanks

Michael

Re: RIPng advertisement hop count 1 (should be 255 per RFC)

Simon Dickhoven — 2013-06-19T00:37:56

Hi, again

If you were paying attention (unlike myself) you may have noticed that 
the below fix doesn't actually make BIRD RFC-compliant.

Rather, it makes BIRD interoperate with other RFC-compliant RIPng routers.

After all, the RFC doesn't state that route advertisements must be sent 
with an HLIM of 255 (though that's implied, of course), but rather that 
routers must _check_ that the HLIM is 255 when they _receive_ routing 
updates.

I tried getting that to work by checking s->ttl in the rip_rx function. 
However, that always returns 255 (or, I suspect, whatever rif->sock->ttl 
was set to in the new_iface function) regardless of the incoming 
packet's HLIM.

I then tried using the sk_set_min_ttl function on the socket in the 
new_iface function but got this error:

     Kernel does not support IPv6 TTL security

(i.e. the socket protocol doesn't support that option). Since I'm on 
Linux (Debian) this error comes from sysdep/linux/sysio.h.

Anyway, I am not familiar enough with the BIRD code to understand where 
I can obtain the actual HLIM (TTL) of the incoming packet in order to 
ensure that the HLIM (TTL) is 255.

I'll keep digging but if anybody has any suggestions or pointers to get 
me moving in the right direction I'd appreciate it.

Thanks.

- Simon

On 06/14/2013 05:41 PM, Simon Dickhoven wrote:

Re: Not re-exporting learned OSPF routes

Ryan Whelan — 2013-06-18T12:57:23

That would be helpful-  it'd be nice to not have to keep the same setting
in multiple places in the config file


On Tue, Jun 18, 2013 at 4:50 AM, Ondrej Zajicek <santiago< at >crfreenet.org>wrote:

Re: RIPng advertisement hop count 1 (should be 255 per RFC)

Ondrej Zajicek — 2013-06-18T11:41:54

Hello

Thanks for the bugreport and patch. As i understand RFC 2080, hop limit
255 should be used just for RIPng multicast messages. You could try the
attached patch, which will use hop limit 255 for multicast and hop limit
1 for unicast (although RFC 2080 is IMHO unclear about hop limit for
unicast).

Re: Testing framework

Sam Russell — 2013-06-18T09:53:56

Do you have any preferences or recommendations for a unit testing
framework? Distributed network software isn't too hard - if you abstract
out the socket stuff you're just dealing with packets being sent to a
callback function - and if packets can be sent to it, then test data works
fine too. It takes a bit longer to write the first lot of tests, but it's
really important to have them - very good for verifying RFC compliance
(e.g. the recent RIPng TTL isue) as well as finding bugs.

Does anyone know of a good C unit testing framework?


On Tue, Jun 18, 2013 at 9:09 PM, Ondrej Zajicek <santiago< at >crfreenet.org>wrote:

Re: Testing framework

Ondrej Zajicek — 2013-06-18T09:09:48

There is no systematic unit test framework, there are some tests
scattered in code (like filter/test.conf or 'ifdef TEST' code in
nest/rt-fib.c). Some simple (perhaps make based?) unit testing framework
could be useful, OTOH distributed network software is pretty hard to
test by unit testing (you could test consistency of some core data
structures, but testing standards compliance for e.g. OSPF is much
harder problem).

Re: Not re-exporting learned OSPF routes

Ondrej Zajicek — 2013-06-18T08:50:09

It is not currently possible, you have to copy the options.

I don't think that setting per-area defaults is the best way how to
solve this. It is not uncommon to have several classes of ifaces with
different sets of options. Perhaps named iface templates, like ones
used for protocols, could solve this issue in a better way:

template "wired" { hello 3; retransmit 2; wait 10; dead 15; check link; };
template "wireless" { hello 5; retransmit 2; wait 10; dead 60; };

interface "eth0" from "wired" { cost 10; };
interface "eth1" from "wired" { cost 20; };
interface "wlan0" from "wireless" { cost 100; };
interface "wlan1" from "wireless" { cost 200; };

Any comments?

Re: Route withdrawn via pipe to another kernel table causessegfault crash

Ondrej Zajicek — 2013-06-18T08:35:30

Yes, of course.

Testing framework

Sam Russell — 2013-06-17T20:48:41

Is there a set of unit tests for BIRD somewhere? I don't know where I'd
start building them, but I'm happy to do the legwork on the coding - unit
testing will make it a lot easier to add new modules and guarantee the
functionality of existing ones.

Doc and doc not syncing together on windows

Sam Russell — 2013-06-17T08:14:31

Is there any chance we could rename either the "doc" folder or the "Doc"
document? I'm doing dev on a variety of machines, and on my windows machine
I can only sync one because windows isn't case sensitive.

Re: Not re-exporting learned OSPF routes

Ryan Whelan — 2013-06-15T18:41:12

Wow- thanks for the quick response guys!  This works great!

Is it possible to set the dead timer, auth ttype, password, etc per area
and only override the interface differences (like cost) on a per interface
basis? (having the interfaces inherit the non-specified settings from the
area config)


On Mon, Jun 10, 2013 at 10:29 AM, Daryl Turner <daryl.turner< at >gmail.com>wrote:

Re: Route withdrawn via pipe to another kernel table causes segfault crash

Joel Mulkey — 2013-06-15T05:12:56

Ondrej,

I can confirm that this did fix the issue. Thank you for fixing this, and so quickly. Should I assume this change will be included in release 1.3.11? 

Joel Mulkey

On Jun 12, 2013, at 6:01 AM, Ondrej Zajicek wrote:

Re: RIPng advertisement hop count 1 (should be 255 per RFC)

Simon Dickhoven — 2013-06-15T00:41:10

OK. I looked at proto/rip/rip.c a bit more and figured that I might as 
well give it a shot and hack around a little bit. I ended up making this 
tiny mod:

--- a/proto/rip/rip.c
+++ b/proto/rip/rip.c
< at >< at > -706,7 +706,11 < at >< at >
    rif->sock->dport = P_CF->port;
    if (new)
      {
+#ifndef IPV6
        rif->sock->ttl = 1;
+#else
+      rif->sock->ttl = 255;
+#endif
        rif->sock->tos = IP_PREC_INTERNET_CONTROL;
        rif->sock->flags = SKF_LADDR_RX;
      }

Subsequently, I did a full Debian package build based on

http://backports.debian.org/debian-backports/pool/main/b/bird/bird_1.3.7-1~bpo60+1.diff.gz

I added the above patch to the debian/patches dir and appended the patch 
file name (I named it "011-ripng_hopcount.patch") to debian/patches/series.

The package built fine. I installed it on my test box and lo and behold: 
Vyatta/Quagga is now happy and I'm seeing my IPv6 routes propagate via 
RIPng.

Tcpdump reveals that RIP(v2) is still using a TTL of 1 and RIPng is 
using an HLIM (IPv6 equivalent of TTL) of 255.

Thanks.

- Simon

On 06/14/2013 03:04 PM, Simon Dickhoven wrote:

RIPng advertisement hop count 1 (should be 255 per RFC)

Simon Dickhoven — 2013-06-14T22:04:25

Hi,

I just started experimenting with BIRD for an IPv6 deployment. I am 
using Vyatta VC6.6R1 router VMs on either side of my BIRD VM (which runs 
on a customized Debian Squeeze release with kernel 3.3.1). I installed 
bird/bird6 1.3.7 from the squeeze-backports repository.

Here my setup.

Lab Net --- Vyatta --- BIRD on Debian --- Vyatta --- Stub Net

Anyway, I don't have any problems with my configs or anything like that. 
My problem is that Vyatta's ripngd (part of Quagga) complains about an 
RFC violation when it receives RIPng advertisements from BIRD:

Jun 14 21:43:40 vyatta ripngd[1682]: RIPng packet comes with non 255 hop 
count 1 from fe80::20c:29ff:fef8:cbc5

I looked at the source code in rip.c and see this line:

       rif->sock->ttl = 1;

which is the only reference I can find to TTL/Hop Count. So I'm guessing 
this is the culprit. The latest source code (1.3.10) is identical in 
this respect.

RFC 2080 states

[...]
As an additional check, periodic advertisements must have their hop 
counts set to 255, and inbound, multicast packets sent from the RIPng 
port (i.e. periodic advertisement or triggered update packets) must be 
examined to ensure that the hop count is 255.
[...]

The use of the term "must" leads me to believe that this is not optional 
and is therefore required for RFC-compliance.

There seems to be no such requirement for RIP (v1/v2) so simply changing 
the source code to indiscriminately set the TTL to 255 is probably not 
the right thing to do.

Have others encountered this problem and is there possibly a patch or 
something for getting RFC-compliance and hence interoperability with 
Vyatta/Quagga(ripngd)?

Thanks.

- Simon

Re: Building in OpenFlow/SDN support

Sam Russell — 2013-06-14T10:26:38

Tun/tap is just one way to do it - another way would be to make the
interfaces all virtual, and send the routing protocol stuff out a
different interface. The big problem we've found with routing
protocols being sent over the OpenFlow control channel is that it can
often only handle 10-50 packets per second, so it'd be better to send
this on a direct VLAN to the switch instead of tun/tap

Sent from my iPhone

On 14/06/2013, at 10:02 PM, Ondrej Zajicek <santiago< at >crfreenet.org> wrote:

Re: Building in OpenFlow/SDN support

Ondrej Zajicek — 2013-06-14T10:32:56

Hi

This is interesting and would be nice to have, but i don't understand
one detail. I understand why you need replacement for kernel proto to
translate routes to flows for SDN, but i don't understand why you need
replacement for device proto to create fake interfaces if you also plan
to use tun/tap - in that case you would already have 'real' tun/tap
ifaces which would be enumerated in BIRD in a standard way.

Re: Building in OpenFlow/SDN support

Sam Russell — 2013-06-14T09:22:25

Thanks for the reply Ondrej,

The reason I want to separate both the kernel and devices is to build
something like RouteFlow - create fake interfaces that relate to physical
interfaces on a router, assign IPs to them (and drive ARP and ping from
that), but also translate the routes from the fake kernel into flows on the
router.

I've covered tun/tap with openflow on my blog
http://pieknywidok.blogspot.co.nz/2012/09/tunneling-traffic-through-your-openflow.html?m=1but
the next step is to build it into a router.

Cheers
Sam

Sent from my iPhone

On 14/06/2013, at 8:50 PM, Ondrej Zajicek <santiago< at >crfreenet.org> wrote:

On Fri, Jun 14, 2013 at 11:16:00AM +0200, Ondrej Zajicek wrote:

On Fri, Jun 14, 2013 at 04:14:19PM +1200, Sam Russell wrote:

Thanks for the reply. I think the kernel/iface stuff is a little bit more

complicated than you've explained - there are lots of places around the

code where calls are made directly rather than referring to the functions

in the proto structure.


Well, we should discuss separately kernel protocol and device protocol.

Kernel protocol is essentially just another protocol (there is one small

hack when kernel protocol abuses attached kernel table by temporarily


Here should be 'attached BIRD table' instead of 'attached kernel table'.

Re: Building in OpenFlow/SDN support

Ondrej Zajicek — 2013-06-14T09:21:32

Here should be 'attached BIRD table' instead of 'attached kernel table'.