On Tue, Sep 27, 2016 at 03:09:52PM +0000, Neil Jerram wrote:
Hi BIRD users!
Attached are 3 patches that my team has been using for routing through IP-in-IP tunnels, rebased on 1.6.1. I'd like to explain why we find them useful, and start a conversation about whether they or something like them could be upstreamed (or perhaps if there's some better way of achieving our aims). ... 1. Does the routing approach above make sense? (Or is there some better or simpler or already supported way that we could achieve the same thing?)
Hi Using BGP-based routing in NBMA tunnels is an interesting approach. We definitely should support this. But i would avoid things like 'krt_tunnel' attribute until we have support for lightweight tunnels using RTA_ENCAP. For IPIP tunnels, it seems like simplest approach is just to allow setting 'onlink' flag and iface from BGP import filter, like: onlink = true; iface = "tunl0"; gw = bgp_nexthop; and some option that avoids default gateway setting by BGP protocol. Does this make sense? BTW, it seems that this approach works for NBMA IPIP tunnels but not for NBMA GRE tunnels, due to a hack that IPIP code accepts 'onlink' gw as an outer IP address, while GRE code resolves next hops through 'neighbor cache' to get outer IP addresses, so this must be used to get similar behavior: ip neigh add 10.1.1.1 lladdr 10.1.1.1 dev gre0 ip route add 10.1.2.0/24 via 10.1.1.1 dev gre0 onlink This is conceptually more clear and has some other advantages, but in this case IPIP behavior is more useful. Does anybody know if there is a way how to convince GRE iface to behave like IPIP iface in this regard? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."