[Dibbler] Problems with multiple relays

Kristoffer Fredriksson kf at fourdays.com
Tue May 10 19:44:43 CEST 2005


We have now tested the new version and the server seems to successfully 
decode the request using 2 relays and sends an answer back. However the relay 
closest to the server drops the answer from the server and doesn't relay it 
back to first relay. The following error is reported:

"Relay Warning  Invalid INTERFACE_ID option, expected lenght 8, actual lenght 
4."

We get the same error if we only use one relay. (Without any relay everything 
works fine...)

Topology: client--relay2---relay1---server

Configfiles and logs are attached. (Note that the time-stamps are wrong in 
the logs.)

Sincerely,
Kristoffer F and the rest of the IPv6-lab-group.

----------------------------------------------------------------
On Tue, 3 May 2005 00:39:56 +0200 (CEST), Tomasz Mrugalski wrote
> On Fri, 22 Apr 2005 somebody known as kf wrote:
> 
> > Thank you for your reply. Your work is appreciated.
> >
> > Here is the full view of our network topology. Keep in mind that this is a
> > lab-setup:
> > http://www.fourdays.com/dibb/Full_network_topology_IPv6.png
> I have prepared fixed version, which works fine over 2 relays. 
> Additional relays (up to 32) should fine. Download sources or Linux 
> binary to check if this fixes your problem.
> 
> Sorry it took so long. I had some serious issues to gather so much 
> equipment in my home. And debugging something like this (4 hosts)
>  was kind of a challenge. But I belive it should work now.
> 
> http://klub.com.pl/dhcpv6/ Section "Download: unstable"
> 
> Take a look at included config files (2-*.conf). To support multiple 
> relays, server must have defined all relays, one by one. First relay 
> uses physical (e.g. eth0) as a underlaying interface. Next relay 
> uses the previous one as underlaying.
> 
> This approach has both flaws and benefits: An advantage is that 
> administrator has a direct control over when requests can arrive. 
> Disadvantage is that server config file contains some informations 
> about network structure.
> 
> Please let me know if this works for you.
> 
> Interesting fact: Ethereal 0.10.9 (a popular open source packet 
> sniffing tool) does not display RELAY-REPL properly (RELAY_FORW 
> looks ok). I have inspected RELAY-REPL messages byte after byte and 
> I belive that messages are generated ok and that it is a Ethereal 
> flaw. If someone belives otherwise, I'm open for debate or suggestions.
> 
> Regards,
> 
> -- 
> Tomasz Mrugalski,              | "I think there is a world market 
> for     | thomson(at)klub(dot)com(dot)pl |  about five computers."   
>                |                                |     Thomas J. 
> Watson (Chairman, IBM) 1943| _______________________________________________
> Dibbler mailing list
> Dibbler at klub.com.pl
> http://klub.com.pl/cgi-bin/mailman/listinfo/dibbler

-------------- next part --------------
log-mode short
iface eth0
{
    IA
}
-------------- next part --------------
log-level 8
log-mode full

iface eth2 {
 server multicast yes
}

iface eth1 {
 client unicast 6011::1
 interface-id 6011
}

-------------- next part --------------
log-level 8
log-mode short

iface eth2 {
	server unicast 6011::1
}


iface eth0 {
  client multicast yes
  interface-id 6021
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: relay2.log
Type: application/octet-stream
Size: 851 bytes
Desc: not available
Url : /lists/attachments/20050510/6c9f00b0/relay2.obj
-------------- next part --------------
log-level 8
log-mode short

iface relay1
{
	relay eth0
	interface-id 6011
}

iface relay2
{
	relay relay1
	interface-id 6021

  class {
	pool 6010::20-6010::ff
 }
}


-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.log
Type: application/octet-stream
Size: 1696 bytes
Desc: not available
Url : /lists/attachments/20050510/6c9f00b0/server.obj


More information about the Dibbler mailing list