Hi, guys ! I'm trying to use bird/OSPF on a bunch of gre tunnels. Though I'm using it successfully with ipv6 on same tunnels, I have no clue why it doesn't announce the networks when on ipv4. My typical setup is as follows: VPN HUB <-----WAN/gre/OSPF-----> branch router <--local-network--> At this time VPN HUB runs quagga/ospfd (due to this problem I'm talking about). I receive all the routing updates from HUB on a branch router, but HUB doesn't get anything from a branch router: HUB: # ifconfig gre14 gre14: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.3.24 --> 192.168.6.191 inet 172.16.3.134 --> 172.16.3.135 netmask 0xffffffff inet6 fe80::21a:64ff:fe21:8e80%gre14 prefixlen 64 scopeid 0x2b nd6 options=3<PERFORMNUD,ACCEPT_RTADV> # vtysh [...] sh ip ospf nei [...] 192.168.6.191 1 Full/DROther 38.434s 172.16.3.135 gre14:172.16.3.134 0 0 0 # route -n get 192.168.9.0/27 route: writing to routing socket: No such process Branch: # birdc -s /var/run/bird.ctl BIRD 1.3.8 ready. bird> show ospf neighbors ospfv4: Router ID Pri State DTime Interface Router IP 192.168.3.24 1 full/ptp 00:33 gre0 172.16.3.134 bird> sh route protocol direct1 192.168.6.128/25 dev vr2 [direct1 14:02] * (240) 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) bird> sh route filter exportospfv4 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.6.191 --> 192.168.3.24 inet 172.16.3.135 --> 172.16.3.134 netmask 0xffffffff inet6 fe80::20d:b9ff:fe20:d980%gre0 prefixlen 64 tentative scopeid 0x9 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Thanks. Eugene.
On Tue, Aug 21, 2012 at 08:29:20PM +0600, Eugene M. Zheganin wrote:
Hi, guys !
I'm trying to use bird/OSPF on a bunch of gre tunnels. Though I'm using it successfully with ipv6 on same tunnels, I have no clue why it doesn't announce the networks when on ipv4.
My typical setup is as follows:
VPN HUB <-----WAN/gre/OSPF-----> branch router <--local-network-->
At this time VPN HUB runs quagga/ospfd (due to this problem I'm talking about). I receive all the routing updates from HUB on a branch router, but HUB doesn't get anything from a branch router:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga. I guess that changing IP addresses on PTP link to a proper prefix (i.e. 172.16.3.132/30) may help. Also it would be a good idea to check whether both sides use the iface in the same mode (broadcast/ptp/ptmp/nbma), but this is relevant only on ifaces with proper IP prefix, with current addresses broadcast and NBMA cannot be used, so it is probably OK. -- 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."
Hi. On 22.08.2012 14:39, Ondrej Zajicek wrote:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga. As far as I understand unnumbered interfaces are those that have something like this
interface Loopback0 ip address 1.1.1.1/255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0 And I have no knowledge about quagga possibilities here, and no such configuration in my quagga too.
I guess that changing IP addresses on PTP link to a proper prefix (i.e. 172.16.3.132/30) may help. Excuse me, but why do you consider /32 prefix as improper ? It seems to be correct for a pointopoint link. Furthrermore, /30 for a pointopoint subnetting wastes exactly one half of IP adddresses, of course in my case they are private, but still. Anyway, I tried to set /31 on the bird side, it didn't help too.
I should say that regardless to that, quagga still can interoperate with a cisco ipinip/gre tunnel configured on the cisco side as /30 or /31, while quagga configured as /32 on the interface itself and as /31 in the area configuration.
Also it would be a good idea to check whether both sides use the iface in the same mode (broadcast/ptp/ptmp/nbma), but this is relevant only on ifaces with proper IP prefix, with current addresses broadcast and NBMA cannot be used, so it is probably OK. Yes, they are both in the pointtopoint mode.
Thanks. Eugene.
On Wed, Aug 22, 2012 at 04:32:24PM +0600, Eugene M. Zheganin wrote:
Hi.
On 22.08.2012 14:39, Ondrej Zajicek wrote:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga. As far as I understand unnumbered interfaces are those that have something like this
interface Loopback0 ip address 1.1.1.1/255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0
And I have no knowledge about quagga possibilities here, and no such configuration in my quagga too. ... Excuse me, but why do you consider /32 prefix as improper ?
Generally, i consider that network has proper IP prefix if all interfaces connected to that network share that prefix [*] (i.e. 192.168.1.10 and 192.168.1.20 in 192.168.1.0/24, or even 192.168.1.10 and 192.168.1.11 in 192.168.1.10/31). This is usual network setup. Another possibility is 'unnumbered' as you wrote above (i.e. IP address just for loopback). Third possibility is 'ptp' addressing as set by 'ip addr add 192.168.1.10 peer 192.168.1.20' on Linux. I am not sure whether these two other possibilities are standardized in some RFC (i suppose they are just some nonstandard but common extensions). Esp. 'ptp' addressing is not discussed in OSPF RFC. I always considered the 'ptp' addressing as a variant of real 'unnumbered' addressing, as it is in most ways very similar to 'real' unnumbered variant - you just give a hint what is IP of the other side, which is useful for running pseudo-unnumbered links on broadcast media like ethernet, where you could have several problems with 'real' unnumbered setups. There are some assumptions that depend on how you consider 'ptp' addressing. For example whether these 'ptp' addresses have to be unique on each iface or whether you could share local IP between several ifaces. [*] for simplicity assume one IP per iface and one prefix per network. But back to your problem. Perhaps i jumped to conclusions here. When i looked at the output you sent it seemed that Quagga does not have BIRD as neighor, while BIRD has Quagga as full/ptp, is this true? That would be probably different problem, as the mentioned one is related to routing table calculation, not neighbor establishment. You could also try the attached patch for BIRD, if the connection works with it, then it is the mentioned problem. -- 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."
owner-bird-users@atrey.karlin.mff.cuni.cz wrote on 2012/08/22 15:34:54:
On Wed, Aug 22, 2012 at 04:32:24PM +0600, Eugene M. Zheganin wrote:
Hi.
On 22.08.2012 14:39, Ondrej Zajicek wrote:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga.
Yes, they went in a few weeks ago too :) ( there is one patch outstanding though) current released quagga cannot handle ifindex in the LSA(like BIRD do for /32 masks). This is an old defect in Q. so BIRD is not to blame.
As far as I understand unnumbered interfaces are those that have something like this
interface Loopback0 ip address 1.1.1.1/255.255.255.255 ! interface Tunnel0 ip unnumbered Loopback0
And I have no knowledge about quagga possibilities here, and no such configuration in my quagga too. ... Excuse me, but why do you consider /32 prefix as improper ?
Generally, i consider that network has proper IP prefix if all interfaces connected to that network share that prefix [*] (i.e. 192.168.1.10 and 192.168.1.20 in 192.168.1.0/24, or even 192.168.1.10 and 192.168.1.11 in 192.168.1.10/31). This is usual network setup.
Yes, a /32 mask is not a "proper" prefix so you are quite right. What to do with these varies in existing ospf impl. Jocke
On Wed, Aug 22, 2012 at 04:32:26PM +0200, Joakim Tjernlund wrote:
owner-bird-users@atrey.karlin.mff.cuni.cz wrote on 2012/08/22 15:34:54:
On Wed, Aug 22, 2012 at 04:32:24PM +0600, Eugene M. Zheganin wrote:
Hi.
On 22.08.2012 14:39, Ondrej Zajicek wrote:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga.
Yes, they went in a few weeks ago too :) ( there is one patch outstanding though) current released quagga cannot handle ifindex in the LSA(like BIRD do for /32 masks). This is an old defect in Q. so BIRD is not to blame.
Although i agree that next hop computation in Quagga is mainly to blame, i reviewed the issue and it seems that there are some grey areas: 1) RFC 2328 does not really specify how next-hop should be computed on ptp ifaces (it is supposed that there is no need for next-hop). Although it is true that Quagga way is broken w.r.t. unnumbered links (and probably also parallel ptp links), it cannot be said that it is contrary to OSPF spec. 2) Surprisingly, even RFC 5309 (ptp links over LAN) does not specify how next-hop should be computed (although it notes its importance). 3) I thought that for some reasons the ifindex in 'data' value of link in router LSA is somehow important in link-back check or next-hop calculation when there are parallel links, but it seems to be completely useless - local router does not need it and neighboring routers can't map their links to links in local router LSA, because they don't know local ifindexes. Therefore, i think about putting local IP address for ptp links with ptp addresses (i.e. merging the patch i sent before). Although it could be argued that it is contrary to RFC 2328 12.4.1 [*], the ifindex value is useless and using local IP addres would fix compatibility with Quagga and Mikrotik (which seems to have the same problem). Any comments? [*] "For unnumbered point-to-point links, the Link Data field should be set to the unnumbered interface's MIB-II [Ref8] ifIndex value." -- 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."
On Thu, 30 Aug 2012, Ondrej Zajicek wrote:
Therefore, i think about putting local IP address for ptp links with ptp addresses (i.e. merging the patch i sent before). Although it could be argued that it is contrary to RFC 2328 12.4.1 [*], the ifindex value is useless and using local IP addres would fix compatibility with Quagga and Mikrotik (which seems to have the same problem).
Any comments?
[*] "For unnumbered point-to-point links, the Link Data field should be set to the unnumbered interface's MIB-II [Ref8] ifIndex value."
It can be conditional on a configurable option, that should provide maximum forward compatibility. I have no idea about Mikrotik, but we could work with quagga to get it fixed there as well... What does Cisco and Juniper boxes do? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Hi. On 30.08.2012 17:09, Henrique de Moraes Holschuh wrote:
It can be conditional on a configurable option, that should provide maximum forward compatibility. I have no idea about Mikrotik, but we could work with quagga to get it fixed there as well... That would be just great, as for now it's pretty obvious that quagga development is stalling. I wish I could migrate to bird, but right now I have no idea about how to do it with a bunch of running quaggas. What does Cisco and Juniper boxes do?
Cisco doesn't support /32 on ptp interfaces (at least on my devices/IOSes), but it supports /31 and these ptp links are interoperable with quaggas and with JunOS. JunOS uses /32 on its p2p interfaces (at least all the examples are abount /32). I could try to link bird with juniper via p2p and report here abount what happens. Eugene.
Ondrej Zajicek <santiago@crfreenet.org> wrote on 2012/08/30 12:57:30:
On Wed, Aug 22, 2012 at 04:32:26PM +0200, Joakim Tjernlund wrote:
owner-bird-users@atrey.karlin.mff.cuni.cz wrote on 2012/08/22 15:34:54:
On Wed, Aug 22, 2012 at 04:32:24PM +0600, Eugene M. Zheganin wrote:
Hi.
On 22.08.2012 14:39, Ondrej Zajicek wrote:
As i understand it correctly, you have Quagga at one end and BIRD on the other? AFAIK there is some problem related to unnumbered ptp links in Quagga which causes incompatibility with BIRD, Joakim Tjernlund has some patches for that for Quagga.
Yes, they went in a few weeks ago too :) ( there is one patch outstanding though) current released quagga cannot handle ifindex in the LSA(like BIRD do for /32 masks). This is an old defect in Q. so BIRD is not to blame.
Although i agree that next hop computation in Quagga is mainly to blame, i reviewed the issue and it seems that there are some grey areas:
1) RFC 2328 does not really specify how next-hop should be computed on ptp ifaces (it is supposed that there is no need for next-hop). Although it is true that Quagga way is broken w.r.t. unnumbered links (and probably also parallel ptp links), it cannot be said that it is contrary to OSPF spec.
2) Surprisingly, even RFC 5309 (ptp links over LAN) does not specify how next-hop should be computed (although it notes its importance).
3) I thought that for some reasons the ifindex in 'data' value of link in router LSA is somehow important in link-back check or next-hop calculation when there are parallel links, but it seems to be completely useless - local router does not need it and neighboring routers can't map their links to links in local router LSA, because they don't know local ifindexes.
It is useless now but bird used ifindex earlier to find its interface and I think many impl. still does.
Therefore, i think about putting local IP address for ptp links with ptp addresses (i.e. merging the patch i sent before). Although it could be argued that it is contrary to RFC 2328 12.4.1 [*], the ifindex value is useless and using local IP addres would fix compatibility with Quagga and Mikrotik (which seems to have the same problem).
Any comments?
That sounds like a good idea. In a way Quagga already does this as it doesn't support unnumbered yet but allows /32 prefixes. However, it could possibly break other routers unnumbered impl. I recall from when I devised the clever way to find the interface that (at least for Quagga), any other method would break when using unnumbered on just one side of the ppp link. I cannot remember the details now. Think about it and let me know if you come to the same conclusion. To be on the safe side you could make it configurable. Jocke
On Thu, Aug 30, 2012 at 01:33:09PM +0200, Joakim Tjernlund wrote:
Therefore, i think about putting local IP address for ptp links with ptp addresses (i.e. merging the patch i sent before). Although it could be argued that it is contrary to RFC 2328 12.4.1 [*], the ifindex value is useless and using local IP addres would fix compatibility with Quagga and Mikrotik (which seems to have the same problem).
Any comments?
That sounds like a good idea. In a way Quagga already does this as it doesn't support unnumbered yet but allows /32 prefixes.
However, it could possibly break other routers unnumbered impl. I recall from when I devised the clever way to find the interface that (at least for Quagga), any other method would break when using unnumbered on just one side of the ppp link. I cannot remember the details now. Think about it and let me know if you come to the same conclusion.
I don't think it could break compatibility with other routers - ifindex is not propagated in any other place in OSPFv2, so even if other routers would expect there ifindex, they cannot compare that value to anything so they couldn't know that given IP address is not an ifindex. Putting random value instead of ifindex would probably work too. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> wrote on 2012/08/30 15:42:50:
On Thu, Aug 30, 2012 at 01:33:09PM +0200, Joakim Tjernlund wrote:
Therefore, i think about putting local IP address for ptp links with ptp addresses (i.e. merging the patch i sent before). Although it could be argued that it is contrary to RFC 2328 12.4.1 [*], the ifindex value is useless and using local IP addres would fix compatibility with Quagga and Mikrotik (which seems to have the same problem).
Any comments?
That sounds like a good idea. In a way Quagga already does this as it doesn't support unnumbered yet but allows /32 prefixes.
However, it could possibly break other routers unnumbered impl. I recall from when I devised the clever way to find the interface that (at least for Quagga), any other method would break when using unnumbered on just one side of the ppp link. I cannot remember the details now. Think about it and let me know if you come to the same conclusion.
I don't think it could break compatibility with other routers - ifindex is not propagated in any other place in OSPFv2, so even if other routers would expect there ifindex, they cannot compare that value to anything so they couldn't know that given IP address is not an ifindex. Putting random value instead of ifindex would probably work too.
Ahh, now I recall. It was the other way around so no problem. Jocke
On Thu, Aug 30, 2012 at 01:33:09PM +0200, Joakim Tjernlund wrote:
3) I thought that for some reasons the ifindex in 'data' value of link in router LSA is somehow important in link-back check or next-hop calculation when there are parallel links, but it seems to be completely useless - local router does not need it and neighboring routers can't map their links to links in local router LSA, because they don't know local ifindexes.
It is useless now but bird used ifindex earlier to find its interface and I think many impl. still does.
BTW, i think BIRD didn't used the ifindex value in the past. Before current implementation it tried all ptp ifaces that have neighbor with given router ID. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> wrote on 2012/08/30 15:49:53:
On Thu, Aug 30, 2012 at 01:33:09PM +0200, Joakim Tjernlund wrote:
3) I thought that for some reasons the ifindex in 'data' value of link in router LSA is somehow important in link-back check or next-hop calculation when there are parallel links, but it seems to be completely useless - local router does not need it and neighboring routers can't map their links to links in local router LSA, because they don't know local ifindexes.
It is useless now but bird used ifindex earlier to find its interface and I think many impl. still does.
BTW, i think BIRD didn't used the ifindex value in the past. Before current implementation it tried all ptp ifaces that have neighbor with given router ID.
OK, it was guess. I didn't look too close. BTW, have you considered if there might be several next hops in calc_next_hop() for some interfaces(ptmp and broadcast)? I am looking at: struct ospf_neighbor *m = find_neigh(ifa, rid); if (!m || (m->state != NEIGHBOR_FULL)) return NULL; return new_nexthop(po, m->ip, ifa->iface, ifa->ecmp_weight); and /* * In this case, next-hop is the same as link-back, which is * already computed in link_back(). */ if (ipa_zero(en->lb)) goto bad; return new_nexthop(po, en->lb, pn->iface, pn->weight); Jocke
participants (4)
-
Eugene M. Zheganin -
Henrique de Moraes Holschuh -
Joakim Tjernlund -
Ondrej Zajicek