On Mon, Jan 07, 2019 at 01:09:11PM +0530, Sandeep K M wrote:
> On Fri, Jan 4, 2019 at 7:32 PM Geert Stappers wrote:
> > On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote:
> >
> > > Please let me know if any other information is needed.
> >
> > Not yet mentioned in this thread is working connectity between "server"
> > and "client".  This will require temporary manual configuration
> > of an IPv6 address at client. Let say it is 2020::2/120.
> > Then verify with more than "ping". Example given:  `ssh 1040::2`
> >
> > It shall reveal how well router ( with the odd name 'Switch' ) is
> > configured for routing between 1040::/120 and 2020::/120.
> > Also if the ssh deamon is able to send packets out on the right
> > interface.
> >
> > I do know that it might seem a detour. And we also known that
> > original poster is already stuck with current setup. So the "detour"
> > could be a step forward.   Good luck.
> >
> >
> Hi,
> 
> As you suggested I added the IPv6 address 2020::2/120 manually to my client
> 
> # ip -6 addr add 2020::2/120 dev eth1
> 
> when I pinged the server it failed :
> 
> root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> ping: sendmsg: Network is unreachableping: sendmsg: Network is unreachale
> 
> Then I added a default route:
> 
> 
> root@Ubuntu3481:~# ip -6 route add default via 2020::1
> root@Ubuntu3481:~# ip -6 route
> 2020::/120 dev eth1  proto kernel  metric 256
> fe80::/64 dev eth0  proto kernel  metric 256
> fe80::/64 dev eth1  proto kernel  metric 256
> default via 2020::1 dev eth1  metric 1024
> 
> I see the ping is working fine now:
> 
> root@Ubuntu3481:~# ping6 -I 2020::2 1040::2
> PING 1040::2(1040::2) from 2020::2 : 56 data bytes
> 64 bytes from 1040::2: icmp_seq=1 ttl=63 time=0.278 ms
> 64 bytes from 1040::2: icmp_seq=2 ttl=63 time=0.178 ms
> 64 bytes from 1040::2: icmp_seq=3 ttl=63 time=0.172 ms
 
So ICMP packets can roundtrip across the router.
If other packets can, is still unknown.
(As in '> > Then verify with more than "ping". Example given:  `ssh 1040::2`')


Idea is finding out if the original problem could be caused
by incomplete routing rules.



> But when I remove the manually configured IPv6 address and try to get a new
> IPv6 using "dhclient -6 eth1" again it fails. I see the same log lines in
> dnsmasq log:
> 
> Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:54 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> Jan  7 07:19:55 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 
> 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c
> 
> When we have enable-ra configured wont dnsmasq advertise the gateway IP's ?
> Do we need to enable RA even in the switch where relay agent is running ?
> can we configure default gateway to the clients via dhcpv6 options similar
> to IPv4 ?
> 
> 
> PS: If I replace dnsmasq server with ISC DHCP server everything works fine.

And the essential configuration items of the working setup
are correctly transposed to the non-working setup?


Regards
Geert Stappers
Curious about why the DHCPADVERTISE packets aren't seen with a network sniffer.

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to