--On 2 November 2011 13:02:13 +0100 Ondrej Zajicek <santiago@crfreenet.org> wrote:

The patch is OK (as a workaround). Note that the problem is only related to 'unnumbered' ptp links, so the simplest workaround is just to assign (at least /30) regular IP prefix to that link. I am not strongly opposed to add such kind of broken-quagga-compat option, but not sure if it is worth if it is only related to such corner cases.

I am guessing this might be one of the issues affecting us (*). We can't do numbering as we have large numbers of /32s as interface routes. Numbering these would use either 2 or 4 times the address space which is not acceptable. (*) = yes I know I need to send some more debug data :-) Nearly every 'bird ospf' problem seems to have quagga at the root of it right now, though I do think /something/ is going wrong in bird in redistribution of routes around protocol restarts. -- Alex Bligh

--On 2 November 2011 14:08:29 +0100 Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

...

I am guessing this might be one of the issues affecting us (*). We can't do numbering as we have large numbers of /32s as interface routes. Numbering these would use either 2 or 4 times the address space which is not acceptable.

What if you forcefully remove the IA_PEER flag for your ppp interfaces? Then an IP address is send instead of ifIndex in the router LSA. Could be an useful addition to bird.

They are unnumbered veth interfaces (i.e. point to point ethernet tunnel). I'm not sure I can manipulate IA_PEER. -- Alex Bligh

Ondrej,

I forgot, not everyone uses private addresses :-), It seems that using /31 quasi-reqular prefix (RFC 3021) is probably also OK.

Yes. But I can't use those here either :-)

...

What if you forcefully remove the IA_PEER flag for your ppp interfaces? Then an IP address is send instead of ifIndex in the router LSA. Could be an useful addition to bird.

IA_PEER is not a flag of iface, it is internal BIRD flag (of an address) signalizing that there is not a common prefix (it is 'unnumbered'). So it is not possible to forcibly remove that (outside of BIRD).

You perhaps mean IFF_POINTOPOINT system iface flag.

That is what I thought you meant.

Forcibly removing it from physically ptp ifaces (like ppp or slip) is not a good idea as in that case BIRD would think that these ifaces are physically NBMA and does not allow run OSPF in PTP mode on it (just NBMA or PTMP mode).

I don't actually need OSPF to be running on the interfaces in question in the sense of transmitting packets. Currently I'm doing two things: * redistributing the interface networks when these are numbered (e.g. a /28) * redistributing the static /32 routes when they are not. The quagga peer is on a different interface. Perhaps I read the original report wrong: I had read this as (also) causing a problem in external LSAs imported into bird on such links, then reaching Quagga.

It would be possible to run BIRD in PTMP mode on unnumbered iface over physically PTP link (PTMP and PTP mode is very similar) but it is non-standard (RFC implicitly supposes that PTMP is numbered) so it is probably not a good starting point for BIRD-Quagga compatibility (i don't have a clue whether and how PTMP mode is implemented in Quagga).

From days gone by playing with Cisco, OSPF and frame-relay ATM interworking, I dimly recall that this (Running on PTMP mode over a PTP link) does in fact work, and should work because a single point is a degnerate case of multipoint. I don't believe the multipoint standard suggests that there has to be more than one endpoint. I do not recall trying this unnumbered, and I agree the RFC probably implicitly prohibits it.

-- Alex Bligh

Hi Joakim Please point us to your patch that would fix the link data field in LS updates and is still waiting to be merged into quagga. Cheers, Roman On 01/11/11 18:54, Joakim Tjernlund wrote:

...

Hi there

Quagga 0.99.18 fails to use routes learned from bird 1.3.4 via OSPF and point-to-point links. The routes might show up in quagga's routing table, but the nexthop will never be the host running bird despite generating those static routes. In the log of quagga's ospfd you will find these entries:

OSPF: ospf_nexthop_calculation(): could not determine nexthop for link

This issue was discovered and discussed earlier in [1], however the topology patch can not be applied any more to bird nowadays due to structural changes. The attached patch is an update of that old version and applies to bird 1.3.4.

Let me quote from RFC 2328, section 16.1.1 [2], namely: "If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required."

As I understand this sentence and its context, the link data field shall be ignored in "the first case" where "the parent vertex is the root". So I figure, this is quagga's fault (source code [3]). Looking at the source code of quagga, the circumvention of the issue is easier to do in bird than a proper fix in quagga.

Yes, Quagga is broken. I have fixed quaggas SPF to support unnumbered and to make its nexthop calc. independent of link the link data field (luckily BIRD maintainers picked up my idea so BIRD is much better:)

Unfortunately I didn't mange to convince the Quagga maintainers so the patches were never applied. Nowadays Quagga is hardly maintained so there is little chance this ever gets fixed. Maybe if you send a bug report, who knows.

Jocke