ospfd not resyncing
I have a fairly simple set-up, where I have ospfd announcing a few routes to a Juniper router. Twice now, when the Juniper has been unreachable and has then come back on-line, the ospf routes have not reconverged on the Juniper end. It has taken a restart of the OSPF on the Juniper to resync the routes.. I've not tried restarting the ospfd's on the OpenBSD end but I presume that would also solve the issue. I suppose it's plausible this is a JunOS bug, and I'll look into that, but wondered if this is a known issue? OpenBSD/ospfd 4.2 RELEASE. -Paul-
ospfd and new interfaces
With ospfd running I create new vlan and carp interfaces and assign IP addresses. Currently, unless I restart ospfd these are not picked up. (This is on 4.0 release). My requirement is for a scripted/automated set-up to create new interfaces as required, obviously it would be much nicer not to have to completely restart ospfd when I do this. Is it feasible that ospfd could be made to pick up these new interfaces dynamically, or be able to signal one of the processes to look for interface changes? -Paul-
Re: ospfd and new interfaces
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Civati) writes: > With ospfd running I create new vlan and carp interfaces and assign > IP addresses. > Currently, unless I restart ospfd these are not picked up. > (This is on 4.0 release). Of course, as soon as I mail this, I read the 4.1 announcement and note the ospfctl reload option that has been added. Which I'm guessing may solve the above? -Paul-
Re: ospfd and new interfaces
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Stuart Henderson) writes: > 4.1 has ospfctl reload which does this for vlan, I am not convinced > it works for carp* yet but haven't had chance to investigate (I only > noticed today). Just tested but it doesn't work for vlan with me on 4.1 release. -Paul-
Re: ospfd not resyncing
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Claudio Jeker) writes:
> Please send some more infos. What version are you useing (did you test
> -current). Please show the config and necessary ospfctl output. The last
> time I have issues like this was some time ago with point-to-point links
> and that got fixed some time ago. There seems something in common with
> your setups that others usually don't have.
4.2-RELEASE - not tried -current because this is for a production
system.
Next time it happens I will try and grab copies of the database.
Our config is really simple.. note that em3 has lots of vlan
and carp interfaces associated with it.
This ospfd talks to the loopback interface on a JunOS box.
auth-type crypt
auth-md n "xxx"
auth-md-keyid n
redistribute connected set metric 50
area 0.0.0.0 {
interface em2
interface em3 { passive }
interface em1 { passive }
}
-Paul-
Re: ospfd not resyncing
Linden Varley <[EMAIL PROTECTED]> wrote: > Bringing up an old-topic here, but just letting everyone know > I have the exact same problem. It occurs quite often. Surely we can't be the only two people seeing this issue? It's quite fundamental to ospfd working properly.. -Paul-
Re: ospfd not resyncing
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Civati) writes: > This ospfd talks to the loopback interface on a JunOS box. For sake of clarity, over a normal ethernet interface, no PtP. -Paul-
Re: ipsec vpn
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] ("Bryan Irvine") writes:
> Also[1], there may be the need for an occasional connection from users
> just using the windows vpn client. Anybody doing this? I rarely even
> see windows so I'm not sure what to look for there.
> Do I need to import a key of some sort, or set authentication somehow?
My understanding is, if you want to support the simple connection
of Windows clients, using the built-in VPN connector (eg. control
panel -> network -> make new connection -> VPN -> L2TP), the
server side needs:
1. IPSec VPN transport mode, most likely with dynamic IP endpoint
2. L2TP tunneling daemon
3. PPP daemon
You will also need NAT traversal in the server and client IPSec
implementation, if the client is connecting from behind a NAT
firewall/device.
2000 and XP will support NAT traversal with the right service
packs, OpenBSD 4.0, according to my checking of man pages this
evening, should support NAT-T too.
2000 and XP will support authentication using X.509 (ie. SSL
like) certificates, only XP will support PSK (pre-shared-key).
This is from my recent research of trying to get this working
with Debian, but I gave up because the server versions of s/w
I was using didn't support NAT-T, AFAICS. I've not tried it
with OpenBSD, yet.
All AIUI, some of that could be wrong as I've not had it
working yet.
-Paul-
Re: ipsec vpn
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Reyk Floeter) writes: >> 2000 and XP will support authentication using X.509 (ie. SSL >> like) certificates, only XP will support PSK (pre-shared-key). > > i won't necessarily defeat windows, but 2000 and xp do support > kerberos 5, x.509 _and_ pre-shared key authentication by default. Please don't quoute out of context, I was talking about the "stupid wizard" VPN connector not straight IPSec. -Paul-
Re: ipsec vpn
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Reyk Floeter) writes: >> My understanding is, if you want to support the simple connection >> of Windows clients, using the built-in VPN connector (eg. control >> panel -> network -> make new connection -> VPN -> L2TP), the >> server side needs: >> >> 1. IPSec VPN transport mode, most likely with dynamic IP endpoint >> 2. L2TP tunneling daemon >> 3. PPP daemon > > no. you don't need l2tp + ppp. you're not talking about the built-in > ipsec support, you're talking about a stupid wizard... Correct, I wasn't talking about plain IPSec, I was talking about "the simple connection of Windows clients, using the built-in VPN connector" exactly as I wrote. Can we drop the condescending "everyone without an openbsd.org mail address is an idiot" attitude please. I didn't say there was no other possible way to use IPSec on Windows, and my post was quite clear about the method I was talking about. > starting with windows 2000, it is possible to use the built-in ipsec > support. it is a bit hidden and the configuration is painful, but it > actually works... you can configure it from the system management > console or by executing "system32\secpol.msc". Exactly, this is not simple, the "stupid wizard" you refer to is what average joe without in depth IP stack knowledge will want to use, and what some people who have to support client VPN connections may want to use, because it will greatly reduce their support headache - providing server side works smoothly of course. -Paul-
Re: Motherboard recommendations? Pentium IV, 2GB+ RAM?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] ("C. Bensend") writes:
> Needed:
>
> * 1+ PCI-X slot, 64-bit 133MHz (one required)
> * Intel Pentium IV, don't care what socket
> * Minimum 2GB RAM capacity
> * PC3200 RAM, if possible (already have 1GB stick just sitting around)
Supermicro P4SCi (S478) - really designed for Supermicro chassis though.
PCI-X 64bit (only 66MHz I'm afraid) and PC3200 capable.
> Wanted:
>
> * Decent gigabit NIC built in, if possible (ie, not %&[EMAIL PROTECTED]
> Broadcom)
> * 4GB RAM capacity would be nice
Dual Intel gige on-board and 4 slots for up to 4GB RAM.
-Paul-
Re: Motherboard recommendations? Pentium IV, 2GB+ RAM?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Chris Cappuccio) writes: >> I haven't had good luck with AMD64 so far. The server I built not >> a year ago has had more kernel panics and funky-ass behavior than > > Be careful about what kind of motherboard and RAM you buy in the future... > > Motherboard chipset compatibility is also an issue with newer AMD64 stuff People need to understand what they are buying into. You have desktop boards and server class boards. Athlon64 is a desktop processor, Opteron is a server processor, and thus the boards likewise. Generally the server class board will cost twice as much as the desktop board, but have decent manufacturer (Intel or AMD) chipset and the right buses (PCI-X) connected in a sensible manner. If you are buying cheap desktop boards with poorly designed chipsets then they are never going to be good server boards, and you will experience the problems described. -Paul-
