<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Have you tested use realbroadcast flag at bird? It is not compatible
with other softwares but usually it helps when you have wierd
problems at unstable mobile vpn connections to get all clients
initialized. By default ospf use multicast. As sad it is multicast
implementations in kernels, switches etc more or less always broken.
So I suggest to test that. <br>
<br>
Another thing is also that I am not sure how good idea it is run
over 100 client ospf farm at one "L2". I suggest that you run
multiple openvpn servers instances and split connections between
them. That way you can get also reduntancy. If you limit max clients
at server side and add multiple remote addresses to client side your
client will choose next server if first is full. Also if you have
multiple physic servers then it allow helps you when you want update
one of them.<br>
<br>
Naturally that splitting is just workaround for original problem and
then we will not never know what that problem was in first place :)
That why for curiosity I suggest first to test with that "real
bloardact yes" flag at all routers and we will see that is that
problem in bird it self or on openvpn bridge/kernel side. <br>
<br>
<div class="moz-cite-prefix">Magnus Löfqvist kirjoitti 14.10.2017
klo 20.27:<br>
</div>
<blockquote type="cite"
cite="mid:4780f9c2-e354-4db1-814b-a520e3edecf6@vmi.se">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<style>
<!--
.EmailQuote
{margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid}
-->
</style>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12.0pt; line-height:1.3; color:#1F497D">
<div>Hi again,<br>
<br>
Just a throught, we dont need our endpoints to know about each
other, in fact, we do firewalling not to allow traffic between
them.<br>
<br>
Are there any better solutions, instead of ospf, where we can
have more than 100 endpoints getting there routes from a
central server, and where we dont need to specify evry
neigboor at the system?<br>
<br>
/ Magnus<br>
</div>
<div id="signature-x" class="signature_editor"
style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12.0pt; color:#1F497D">
<br>
</div>
</div>
<div id="quoted_header" style="clear:both">
<hr style="border:none; height:1px; color:#E1E1E1;
background-color:#E1E1E1">
<div style="border:none; padding:3.0pt 0cm 0cm 0cm"><span
style="font-size:11.0pt; font-family:'Calibri','sans-serif'"><b>Från:</b>
Magnus Löfqvist<br>
<b>Sänt:</b> 13 okt. 2017 23:31<br>
<b>Till:</b> Ondrej Zajicek<br>
<b>Kopia:</b> <a class="moz-txt-link-abbreviated" href="mailto:bird-users@network.cz">bird-users@network.cz</a> <br>
<b>Ämne:</b> Re: Limit on how many neighbors<br>
</span></div>
</div>
<br type="attribution">
<div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12.0pt; line-height:1.3; color:#1F497D">
<div>Hi,<br>
<br>
I agree with you, it should not be the case here.<br>
But, we are running over mobile networks, and the openvpn
adds some overhead.<br>
<br>
Running some tcpdump shows that the packet lenght of the
hello packet is just about 480, and that should be ok.<br>
<br>
If we change to another openvpn instance/interface and
change over to that it works directly.<br>
<br>
I have also updated bird on our mainrouter to 1.6.3
(latest), but the issue still exist.
<br>
<br>
I have attached our config files (bird.conf (mainrouter),
bird_client.conf (from one of the end router)).
<br>
My OSPF knowlege are limited, so I guess that I have made
some errors :)<br>
<br>
The main feature we need is to distribute some external
routes (10.3.50.0/24, 10.3.60.0/24), and distribute back
the endpoints IP networks (10.98.x.x/30)<br>
<br>
/ Magnus<br>
</div>
<br>
</div>
<div id="x_quoted_header" style="clear:both">
<hr style="border:none; height:1px; color:#E1E1E1;
background-color:#E1E1E1">
<div style="border:none; padding:3.0pt 0cm 0cm 0cm"><span
style="font-size:11.0pt;
font-family:'Calibri','sans-serif'"><b>Från:</b> Ondrej
Zajicek <a class="moz-txt-link-rfc2396E" href="mailto:santiago@crfreenet.org"><santiago@crfreenet.org></a><br>
<b>Sänt:</b> 13 okt. 2017 13:13<br>
<b>Till:</b> Magnus Löfqvist<br>
<b>Kopia:</b> <a class="moz-txt-link-abbreviated" href="mailto:bird-users@network.cz">bird-users@network.cz</a> <br>
<b>Ämne:</b> Re: Limit on how many neighbors<br>
</span></div>
</div>
<br type="attribution">
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText">On Thu, Oct 12, 2017 at 11:43:03AM
+0000, Magnus Löfqvist wrote:<br>
> Hi,<br>
> <br>
> We are running Bird with OSPF between embedded
routers (openwrt) (mobile routers).<br>
> The routers are connected to our main server with
openvpn, and we are using bird ontop on openvpn to deliver
routes to the end routers.<br>
> <br>
> This have worked quite well, but today we notice some
glitches.<br>
> We had some routers that did not finish election (ie,
stand in init instead of being full).<br>
> When we count, there are exactly 100 devices that are
in "full", and 3 in init.<br>
> <br>
> Are there any limit on how many neighbors/routers?<br>
<br>
Hi<br>
<br>
There is AFAIK no hard limit, but there is an issue that
if you have too<br>
many neighbors, you end with Router-LSA that does not fit
into MTU and<br>
will be sent using fragmented IP packets. Which usually
works, but may be<br>
problematic. But that is probably not relevant, as if
there were such<br>
problem, they would stuck in later stage of exchange and
not in 'init'.<br>
<br>
So i have no idea why they stuck in 'init'. Isn't there
any<br>
misconfiguration? Is there anything in logs? Did they
corrected after<br>
restart?<br>
<br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a class="moz-txt-link-abbreviated" href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
wwwkeys.pgp.net)<br>
"To err is human -- to blame it on a computer is even more
so."<br>
</div>
</span></font></div>
</blockquote>
<br>
</body>
</html>