No reason, platform supports 64bit and thought performance will be better on it. Its running well on i386.
-----Original Message----- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart Henderson Sent: Thursday, February 18, 2010 6:13 PM To: misc@openbsd.org Subject: Re: Strange problem | routing issue On 2010-02-18, Shailesh Tyagi <shail...@novanet.net> wrote: > It seems there is a bug in routing with current 4.7 amd64 (build 10 Feb.). I > tried i386 and it worked with same configuration and without any issues. Just > to make sure I even tried reinstalling the amd64 once again thinking I might > have made some mistakes the first time but same results. Following are the > dmsegs from both installations. Although you shouldn't have this type of problem with running amd64 (and after unwrapping your dmesg and diffing them, I see no real differences between your logs from amd64 and i386), is there a particular reason you want to run amd64 on routers rather than i386? > OpenBSD 4.7-beta (GENERIC.MP) #85: Sun Feb 7 17:06:57 MST 2010 Using the MP kernel adds overheads which you probably won't recoup on a router, particularly if you're just taking defaults from upstream (you'd be more likely to see a difference if e.g. you're doing a lot of route filtering or running a route-reflector). > As soon as we start traffic bgp server starts behaving strangely. for example > if we ping any IP, customer side or towards upstream from the bgpd server, > first few seconds we get "no route to host" and after few seconds it starts > getting the response. When we try to ping the same IP again, behavior remain > unchanged. which means it can't get the route for few seconds. We have checked It might be useful to include output from 'route -n monitor' while this is happening. But please, turn off line wrapping in your mail client, it makes your posts very difficult to read. > xxx.xxx.53.0 link#9 UHLc 0 1 - 4 > > vlan101 > > xxx.xxx.53.0/30 link#9 UC 2 0 - 4 > > vlan101 > > xxx.xxx.53.2 link#9 UHRLc 11 5 - 4 > > vlan101 This is odd (similar for the other subnets in your output). Why the cloned host entry for 203.153.53.0? Where is the lo0 entry for 203.153.53.1 that hostname.vlan101 suggests should be there? Looking at ifconfig -A output might give a clue. (btw, you might as well skip obfuscating the addresses/ASN, it just makes it harder to read and doesn't hide anything). CONFIDENTIALITY NOTE : The documents herein contain information, belonging to Novanet Ltd, which is confidential and privileged. Unless you are the intended recipient, you may not use, copy or disclose to anyone the documents or any information contained in or attached to the documents.
