Hi, Its true BIRD does not implement stub router advertisement as an explicit feature, but you can manually set the cost of the stub links. We have a similar need with a route reflector that needs to be kept out of the forwarding path but needs its loopback advertised into OSPF. ### OSPFv2 IPv4 ### protocol ospf coreOSPF { table ospfT; area 0.0.0.0 { interface "em0", "em1" { cost 65535; type ptp; hello 1; dead count 4; authentication cryptographic; password "secret password"; }; interface "lo1" { stub; }; }; } And here is an LSA from an upstream router showing the cost to use the router to reach a remote network using the route reflector as transit. It will only be used for forwarding after all other paths are down, at which point you would be dropping traffic anyway. Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: x.x.x.x (Link Data) Router Interface address: y.y.y.y Number of TOS metrics: 0 TOS 0 Metrics: 65535 Hope that helps, seems to work for us without getting too complicated. Daryl. On 10 June 2013 10:11, Ondrej Zajicek <santiago@crfreenet.org> wrote:

On Fri, Jun 07, 2013 at 08:07:59PM -0400, Ryan Whelan wrote:

...

I feel like this should be simple, but I can't find what I'm looking for...

I have a few of routers spread across the country in a full mesh running OSPF. 'Servers' and 'clients' connect to these 'routers' to connect to one another- each 'server' and 'client' run a basic bird instance they use to share a local address (X.X.X.X/32). The issue is some of the 'servers' connect to multiple 'routers' so if a link between 2 routers is down, OSPF tries to route though a server... ('servers' don't have ip forwarding on)

In short, how do I make sure the 'servers' can run bird to update OSPF with their /32 address but not re-propagate routes they learn from OSPF (so as to not be considered for route selection by the routers)?

Hello

OSPF works in a different way, there is no 're-propagation of routes' in OSPF, OSPF works by mapping network topology and then everyone calculates shortest paths. Every OSPF node is a part of a network topology and it is implicitly assumed to be a router. There is an extension that allows non-routing OSPF node to participate without acting as a transit node (RFC 3137), but this is not implemented in BIRD.

There are some ways to solve your problem:

1) use OSPF only between routers and use a different protocol between servers/clients and routes.

2) use multiple OSPF instances (with different router ID) on servers, one instance for one link to a router, but there would be problems if you would need to share an iface between OSPF instances.

-- 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."

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlG1mEMACgkQw1GB2RHercOazwCeK1XKMlDTxgoVXfeswcpaWkNP AWQAn2h0CjVKy8d+8In2tiXUrKyLbFaB =txgq -----END PGP SIGNATURE-----

I've applied that patch to our BIRD server in the lab and it works a treat. Thanks, Daryl. On 10 June 2013 13:47, Ondrej Zajicek <santiago@crfreenet.org> wrote:

On Mon, Jun 10, 2013 at 10:11:53AM +0100, Daryl Turner wrote:

...

Hi,

Its true BIRD does not implement stub router advertisement as an explicit feature, but you can manually set the cost of the stub links.

Here is a patch that adds OSPF protocol option 'stub router' which enables RFC 3137 stub router behavior for OSPFv2 and also removes R-bit for OSPFv3 (which should do real stub router for OSPFv3, but there are some erratas for OSPFv3 i just noticed, so the patch behavior for OSPFv3 is WiP).

But RFC 3137 essentially just set link costs to 65535, like your config change, and therefore if there is no other route then stub router would still be used.

-- 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 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: 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."