Re: Not re-exporting learned OSPF routes
On Sat, Jun 15, 2013 at 02:41:12PM -0400, Ryan Whelan wrote:
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)
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?
--
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: Not re-exporting learned OSPF routes
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 santi...@crfreenet.orgwrote:
On Sat, Jun 15, 2013 at 02:41:12PM -0400, Ryan Whelan wrote:
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)
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?
--
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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlHAH0EACgkQw1GB2RHercMePwCeMKVrw6K8LsawRiUNCc64JCk5
JD4An2flEzgK5I/JsGRogaZcIbvAu5qc
=WDMI
-END PGP SIGNATURE-
Re: RIPng advertisement hop count 1 (should be 255 per RFC)
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:
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
@@ -706,7 +706,11 @@
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:
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
Propagating /32 from OSPF to BGP
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_1ISP_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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2 (150/1/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2 (150/1/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [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: Propagating /32 from OSPF to BGP
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: 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_1ISP_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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2 (150/1/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2 (150/1/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [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/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [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
