Claudio Jeker wrote:
On Mon, Feb 09, 2009 at 11:43:10AM +0100, Claudio Jeker wrote:
On Mon, Feb 09, 2009 at 02:22:08AM -0800, patrick keshishian wrote:
On Mon, Feb 9, 2009 at 12:53 AM, Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
On a hunch, I tried a 64bit and a 32 bit machine with 1 prefix each.
The 32bit machine adds routes to the kernel without complaint. The
64bit machine complained with send_rtmsg....
Arrg. IPv6 is once again broken by design. For some ridiculous reason
struct sockaddr_in6's size is 28 bytes. So IPv6 fucks up alignment on 64 bit
archs. All hail link local addressing and all the crappy workarounds
needed for it.
Maybe it is too late for me to be thinking about this ... but could
you explain the diff below? Unless I'm missing something obvious, it
looks like it changes behavior for non-64bit archs as well.
Hmm. I think your right. I think a different approach would be better.
Will cook up something later today.
I think this is better. Just compile tested and no real time to test until
later today.
Hi Claudio
Tested on i386 and amd64 test bgp sessions ok
Tested on amd64 production w/2 x ipv4 feeds and 1 x ipv6. Full ipv6
table is installed in the kernel. daemon log shows
Feb 10 09:06:14 gw-nextgen bgpd[8598]: neighbor 2001:470:17:7f::1
(HurricaneHK): state change Connect -> OpenSent, reason: Connection opened
Feb 10 09:06:14 gw-nextgen bgpd[8598]: neighbor 2001:470:17:7f::1
(HurricaneHK): state change OpenSent -> OpenConfirm, reason: OPEN
message received
Feb 10 09:06:14 gw-nextgen bgpd[8598]: neighbor 2001:470:17:7f::1
(HurricaneHK): state change OpenConfirm -> Established, reason:
KEEPALIVE message received
Feb 10 09:06:18 gw-nextgen bgpd[15752]: nexthop 2001:470:17:7f::1 now
valid: directly connected
No errors.
