Hi, Is there a way of turning off the socket listen for OSPF interfaces marked as 'stub'? At the moment I'm running up against the 1024 open file limit on servers (such as VM hosts) with lots of interfaces. I could alter the ulimit but it seems a bit of a waste to have all those open sockets doing nothing. Could the code be altered to open the socket if the interface is reconfigured away from being a stub, or is there another reason for the listen being there on stub interfaces? Rgs Neil
On Mon, Jul 04, 2011 at 03:20:33PM +0100, Neil Wilson wrote:
Hi,
Is there a way of turning off the socket listen for OSPF interfaces marked as 'stub'?
At the moment I'm running up against the 1024 open file limit on servers (such as VM hosts) with lots of interfaces.
I could alter the ulimit but it seems a bit of a waste to have all those open sockets doing nothing. Could the code be altered to open the socket if the interface is reconfigured away from being a stub, or is there another reason for the listen being there on stub interfaces?
No, it is completely pointless. This is one thing i would like to fix soon. If you have a static list of IP/prefixes, one workaround is to activate OSPF just on non-stub interfaces/prefixes and add stub prefixes using 'stubnet' option. -- 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 5 July 2011 11:16:21 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
No, it is completely pointless. This is one thing i would like to fix soon. If you have a static list of IP/prefixes, one workaround is to activate OSPF just on non-stub interfaces/prefixes and add stub prefixes using 'stubnet' option.
I have a similar deployment requirement (lots and lots of interfaces) which don't need ospf running on them, two default routes learnt, routes for the interfaces advertised. As all my routes are directly connected, my plan was simply to redistribute into OSPF. However, the issue here is that some of the routes are interface routes (i.e. routed to the interface rather than the interface being numbered). For reasons I don't fully understand, a numbered interface can form part of an OSPF stubby area, but an interface route can't (wrong LSA type). In the absence of NSSA, is changing the LSA type of redistributed connected and interface routes an option? (this also has the advantage I don't need to reconfigure bird when adding/removing routes). -- Alex Bligh
On Tue, Jul 05, 2011 at 10:09:57AM +0100, Alex Bligh wrote:
--On 5 July 2011 11:16:21 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
No, it is completely pointless. This is one thing i would like to fix soon. If you have a static list of IP/prefixes, one workaround is to activate OSPF just on non-stub interfaces/prefixes and add stub prefixes using 'stubnet' option.
I have a similar deployment requirement (lots and lots of interfaces) which don't need ospf running on them, two default routes learnt, routes for the interfaces advertised.
As all my routes are directly connected, my plan was simply to redistribute into OSPF.
You mean export them to OSPF as external routes? Yes, that is probably the best solution, having too many stub networks have problems (large LSAs) and limits (about several thousands stub networks by one router).
However, the issue here is that some of the routes are interface routes (i.e. routed to the interface rather than the interface being numbered). For reasons I don't fully understand, a numbered interface can form part of an OSPF stubby area, but an interface route can't (wrong LSA type).
You mean that you cannot export external LSAs to stub areas? Yes, that is true.
In the absence of NSSA, is changing the LSA type of redistributed connected and interface routes an option? (this also has the advantage I don't need to reconfigure bird when adding/removing routes).
I do not understand how you want to change the LSA type. -- 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,
As all my routes are directly connected, my plan was simply to redistribute into OSPF.
You mean export them to OSPF as external routes? Yes, that is probably the best solution, having too many stub networks have problems (large LSAs) and limits (about several thousands stub networks by one router).
That was my initial plan, until I discovered bird did not support NSSA, and...
However, the issue here is that some of the routes are interface routes (i.e. routed to the interface rather than the interface being numbered). For reasons I don't fully understand, a numbered interface can form part of an OSPF stubby area, but an interface route can't (wrong LSA type).
You mean that you cannot export external LSAs to stub areas? Yes, that is true.
... that made me want to do the following:
In the absence of NSSA, is changing the LSA type of redistributed connected and interface routes an option? (this also has the advantage I don't need to reconfigure bird when adding/removing routes).
I do not understand how you want to change the LSA type.
OK, what I meant was this. Redistribution into an NSSA creates (from memory) type 7 LSAs. I can't do that (or indeed any redistribution) into a stub area, as I'm only permitted LSA types 1, 2, 3 and 4 in a stub. However, a normal "interface" route (i.e. an attached network) would create a type 2 LSA in a stubby area. I don't quite see why redistributed statics pointing at interfaces should not also generate type 2 LSAs in a stubby area. IE they would behave as if the interface was numbered. How a route "at the interface" rather a numbered interface and an accompanying kernel interface related route be any different from the routing protocol's point of view? I have hundreds (or perhaps thousands) of such routers, each carrying tens (or perhaps hundreds) of interface routes, and I'd really like it if they didn't have to see the LSA's from eachother (i.e. they only heard a default route). I think these days Cisco supports OSPF filtering which is another way to do this I suppose. -- Alex Bligh
On 5 July 2011 14:30, Alex Bligh <alex@alex.org.uk> wrote:
OK, what I meant was this. Redistribution into an NSSA creates (from memory) type 7 LSAs. I can't do that (or indeed any redistribution) into a stub area, as I'm only permitted LSA types 1, 2, 3 and 4 in a stub.
STUB: No Type 5. TSSA: No Type 3/4/5, plus a default summary route. NSSA: No Type 5. If Type 5 needed due to redistribution etc, use Type 7 and convert to Type 5 at ABR. M
--On 5 July 2011 14:48:04 +0100 Matthew Walster <matthew@walster.org> wrote:
On 5 July 2011 14:30, Alex Bligh <alex@alex.org.uk> wrote:
OK, what I meant was this. Redistribution into an NSSA creates (from memory) type 7 LSAs. I can't do that (or indeed any redistribution) into a stub area, as I'm only permitted LSA types 1, 2, 3 and 4 in a stub.
STUB: No Type 5. TSSA: No Type 3/4/5, plus a default summary route. NSSA: No Type 5. If Type 5 needed due to redistribution etc, use Type 7 and convert to Type 5 at ABR.
Indeed, but TSSA and NSSA do not exist within bird AFAIK, so there are no type 7s. Hence stub areas have only LSA types 1-4 inclusive, unless I am missing something. -- Alex Bligh
On Tue, Jul 05, 2011 at 02:30:04PM +0100, Alex Bligh wrote:
However, a normal "interface" route (i.e. an attached network) would create a type 2 LSA in a stubby area.
That is not true - type 2 LSA is created only for non-stub network, with at least two routers. Stub networks are just part of type 1 LSA. So you mean that exporting routes to OSPF would add some stub records to type 1 LSA? That could be done, but it is not implemented (and it is not a trivial change). -- 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 5 July 2011 15:55:05 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jul 05, 2011 at 02:30:04PM +0100, Alex Bligh wrote:
However, a normal "interface" route (i.e. an attached network) would create a type 2 LSA in a stubby area.
That is not true - type 2 LSA is created only for non-stub network, with at least two routers. Stub networks are just part of type 1 LSA. So you mean that exporting routes to OSPF would add some stub records to type 1 LSA? That could be done, but it is not implemented (and it is not a trivial change).
Oops, yes, sorry, my OSPF is rusty. I want redistribute static to (optionally) have the same effect as creating interfaces - i.e. type 1 LSAs. Alternatively, allow inbound filtering of inter-area LSAs so I can just take the default (that's less good because it will still get the LSAs, only to discard them, but at least it won't have to process them). -- Alex Bligh
On Tue, 2011-07-05 at 11:16 +0200, Ondrej Zajicek wrote:
No, it is completely pointless. This is one thing i would like to fix soon. If you have a static list of IP/prefixes, one workaround is to activate OSPF just on non-stub interfaces/prefixes and add stub prefixes using 'stubnet' option.
Well that's good to know. Unfortunately my environment is highly dynamic so the 'stubnet' solution isn't really practical. I want the effects to cascade from the interface changes. I've done a simply patch to the add interface code to stop the socket opening and I now have an interesting selection of segfaults to sort out :) Rgs Neil
On Tue, Jul 05, 2011 at 11:09:54AM +0100, Neil Wilson wrote:
On Tue, 2011-07-05 at 11:16 +0200, Ondrej Zajicek wrote:
No, it is completely pointless. This is one thing i would like to fix soon. If you have a static list of IP/prefixes, one workaround is to activate OSPF just on non-stub interfaces/prefixes and add stub prefixes using 'stubnet' option.
Well that's good to know. Unfortunately my environment is highly dynamic so the 'stubnet' solution isn't really practical. I want the effects to cascade from the interface changes.
I've done a simply patch to the add interface code to stop the socket opening and I now have an interesting selection of segfaults to sort out :)
Yes, i know where these problems are. I will send you a patch soon. -- 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."
participants (4)
-
Alex Bligh -
Matthew Walster -
Neil Wilson -
Ondrej Zajicek