Re: Exporting IPSec routes to OSPF
As far as I know, strongswan (which is closely related to openswan) installs all IPSec routes in table 220 rather than the main table (254). So you should be able to create a second kernel protocol instance that connects to kernel table 220 and does: import all; export none; (the default behavior of bird, so no need to specify explicitly) Or you can create a second routing table in bird, use the kernel protocol to connect the new (bird) table to kernel table 220, and then use the pipe protocol to sync routes between the main (bird) routing table and the second (bird) routing table. You may need an export filter for the existing kernel protocol instance and reject routes with "source = RTS_PIPE" in order not to copy everything from kernel table 220 to the main kernel table. Do an ip rule show You should see something along the lines of: 220: from all lookup 220 So then do ip route show table 220 You should see your IPSec routes in there. I don't know if ipsec-tools work the same way. - Simon On Jul 7, 2013, at 21:58, "Michael Ludvig" wrote: > Hi > > I've got a handful of Linux IPsec gateways, some running OpenSwan some > with ipsec-tools. Each gateway handles a number of tunnels with dozens > of remote subnets. Unfortunately these remote subnets don't show up in > the Linux routing table, i.e. "ip route show" only comes up with the > standard two records for the link subnet and for the default route. > Obviously bird doesn't see the ipsec routes either. > > Now I've got a script that parses the output of "ip xfrm policy show" > and exports them as static routes but that involves a manual rebuild > every time the tunnels change and "birdc configure" to propagate the > changes. > > Is there any way to automatically export these ipsec routes to OSPF? > > Thanks! > > Michael > > 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.
Re: RIPng advertisement hop count 1 (should be 255 per RFC)
Alright. After a lot of digging I got a working RIPng hopcount check.
See attached patch file.
Here's what I did:
1) In order to reduce any deleterious effects of my subsequent
modifications I first introduced a new socket flag in lib/socket.h.
#define SKF_HLIM_RX 8 /* Report Hop Limit for RX packets */
2) I then modified sysdep/unix/io.c to do the following.
2.1) Based on the above flag, I added a setsockopt statement in the
sysio_register_cmsgs function that causes the IPv6 HLIM field to be
passed as ancillary data in the recvmsg call (which takes place in the
sk_read function).
if ((s->flags & SKF_HLIM_RX) &&
setsockopt(s->fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &ok, sizeof(ok))
< 0)
return "IPV6_RECVHOPLIMIT";
2.1.1) In order to actually receive this additional information I had to
increase the control message buffer size by 13 (a number I arrived at
through trial and error and certainly a hack, rather than the correct
way of doing this... FIXME!!!).
#define CMSG_RX_SPACE CMSG_SPACE(sizeof(struct in6_pktinfo) + 13)
2.1.2) For backward-compatibility with RFC 2292 I also included this:
#ifndef IPV6_RECVHOPLIMIT
#define IPV6_RECVHOPLIMIT IPV6_HOPLIMIT
#endif
2.2) Then I reworked the sysio_process_rx_cmsgs function to parse out
the HLIM info from the control message and set the TTL field in the
socket struct (s->ttl) (if and only if the SKF_HLIM_RX flag is set).
(see attached)
3) Finally, I modified proto/rip/rip.c to take advantage of this new
functionality.
3.1) In the new_iface function I set my newly created socket flag.
#ifndef IPV6
rif->sock->ttl = 1;
rif->sock->flags = SKF_LADDR_RX;
#else
rif->sock->ttl = 255;
rif->sock->flags = (SKF_LADDR_RX | SKF_HLIM_RX);
#endif
3.2) Once that was done, the rip_rx function had access to the HLIM info
via the socket struct (s->ttl).
if (s->ttl < 255) {
log( L_REMOTE "%s: Discarding packet with HLIM = %d < 255 from %I on
%s.", p->name, s->ttl, s->faddr, i->iface ? i->iface->name : "(dummy)" );
return 1;
}
As far as I can tell, the only thing that could possible affect other
protocols is 2.1.1). Other than that, all my changes exclusively apply
to RIPng since that's the only code that sets the SKF_HLIM_RX flag. As
long as this flag is not set, all my modifications are disabled and the
code is functionally equivalent to what it was before.
Please feel free to use the above modifications and also to give me
feedback on it.
I have tested these modifications with a Quagga (Vyatta) router and a
Cicso router. I used ip6tables on the Quagga (Vyatta) router to mangle
the HLIM in order to force a rejection of routing updates from it.
ip6tables -t mangle -A OUTPUT -p udp -m udp --sport 521 -j HL --hl-set 10
When I removed the mangle rule, routes were accepted. When I re-added
it, routes were rejected again and removed from the routing table.
Note: The above modifications were made to version 1.3.7 of the source
code so they may not apply to the latest code.
Thanks.
- Simon
PS: I saw that my Cisco router sets the class for RIPng advertisements
to 0xe0 though I couldn't find any RFCs that call for that. The current
BIRD code (or at least version 1.3.7 of the code) doesn't set the class
at all because it hasn't (/hadn't) been defined by an RFC.
On 06/18/2013 05:48 PM, Simon Dickhoven wrote:
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"
wrote:
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 tha
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
Re: RIPng advertisement hop count 1 (should be 255 per RFC)
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"
wrote:
> 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.
>>> [...]
>&g
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
Re: RIPng advertisement hop count 1 (should be 255 per RFC)
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
RIPng advertisement hop count 1 (should be 255 per RFC)
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
