0

I'm setting up and testing IPv6 on our network and have run into a snag with our windows clients..

I've got a Cisco Catalyst 3850 switch setup for ipv6 unicast-routing and have two networks setup on it. The catalyst switch also has a working ipv6 route out to the internet and I've been able to successfully contact public ipv6 server addresses without issue from the switch CLI (from the switch's ipv6 gateway address on either network).

The gateway addresses/networks on the switch are: VLAN 20: 2607:f460:21c0:a020::1/64 VLAN 200: 2607:f460:21c0:a200::1/64

I can ping one of the configured networks from the other with no issue:

ping 2607:f460:21c0:a200::1 source 2607:f460:21c0:a020::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F460:21C0:A200::1, timeout is 2 seconds:
Packet sent with a source address of 2607:F460:21C0:A020::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

There are no ACLs or special routes setup on the switch other than the default ::/0 public route to the internet.

The windows client resides on VLAN 20 and has the static address: 2607:f460:21c0:a020::2/64 with 2607:f460:21c0:a020::1 set as the default gateway..

If I ping the gateway, it works...

C:\Windows\system32>ping 2607:f460:21c0:a020::1

Pinging 2607:f460:21c0:a020::1 with 32 bytes of data:
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms

C:\Windows\system32>tracert -6 2607:f460:21c0:a020::1

Tracing route to 2607:f460:21c0:a020::1 over a maximum of 30 hops

  1     2 ms     2 ms     2 ms  2607:f460:21c0:a020::1

Trace complete.

If I try to ping anything outside the local On-Link network, it fails with an unreachable error:

C:\Windows\system32>ping 2607:f460:21c0:a200::1

Pinging 2607:f460:21c0:a200::1 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 2607:f460:21c0:a200::1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


Tracing route to 2607:f460:21c0:a200::1 over a maximum of 30 hops

  1  Destination host unreachable.

Trace complete.

The fact that the trace fails on the first hop with unreachable implies to me that windows does not seem to be trying to contact the default route but rather is searching for the host on-link...

This doesn't make sense to me, because I have a gateway set, and it has a lower metric than the on-link route..

===========================================================================
Interface List
  7...00 50 56 94 e7 38 ......vmxnet3 Ethernet Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  7    271 ::/0                     On-link
  7    271 ::/0                     fe80::521c:bfff:fe73:1656
  7     16 ::/0                     2607:f460:21c0:a020::1
  1    331 ::1/128                  On-link
  7    271 2607:f460:21c0:a020::/64 On-link
  7    271 2607:f460:21c0:a020:947a:1291:c6e3:b93d/128
                                    On-link
  7    271 fd67:df27:a77::/48       On-link
  7    271 fd67:df27:a77:7777::/96  On-link
  7    271 fe80::/64                On-link
  7    271 fe80::947a:1291:c6e3:b93d/128
                                    On-link
  1    331 ff00::/8                 On-link
  7    271 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Anyone able to help me with this?

2
  • Tried to do a traceroute to your ipv6 address. Apparently I can only get as far as to the ip address 2607:f406:a001:30::1? That hints that there is a routing issue between you and the address I mentioned. Do they share a network path? – Lasse Michael Mølgaard Apr 16 '20 at 0:35
  • You won't get past that due to our/our ISP's firewall. That is our ISP's route to our network. – Robert Meany Apr 16 '20 at 1:14
0

Well, here's what I've just discovered...

When I delete the ::/0 On-Link route, it starts to work. I'm not sure why this would be the case other than going with the assumption that windows must prioritize on-link routes even if their metric is higher than a manually configured route.

Then I asked, "Why would that route even be there?"... I did some digging around and windows enables stateless autoconfiguration (SLAAC) on ipv6 interfaces by default.. This can be disabled by issuing the following command for the interface in question...

netsh inter ipv6 set interface "X" routerdiscovery=disabled

When SLAAC gets disabled, the ::/0 On-Link route gets removed and everything starts to work.

Why SLAAC configures that default on-link route, I don't know.. Bonus points if someone can explain that to me... Here's my suspicion which I'm not going to bother testing - In order to get a proper default route, SLAAC would need to be enabled on my routers (my switches) so they advertise the routes to my windows clients.

I'm staying away from SLAAC because I want to use my own addressing scheme, so I will just disable it on my statically assigned windows servers.

I'm hoping for my dhcp clients that I can configure an option to tell them not to use SLAAC...

2
  • Well you are going to need SLAAC enabled if you have any android devices on your network. They can for some odd reason not understand DHCPv6? – Lasse Michael Mølgaard Apr 16 '20 at 9:01
  • Yeah... Learning these things as I go along. Honestly we don't have much in the way of managed android devices, so they're just gonna be stuck using IPv4. The exception being our BYOD network where I could enable it.. – Robert Meany Apr 17 '20 at 12:37
0

The ::/0 route was only occurring on a few of my servers.. I could delete the route and it wouldn't come back.. SLAAC would then start working.

I still ended up disabling SLAAC on my managed networks since we don't really use android devices. I like having everything managed by DHCPv6, and I was having trouble getting DDNS registration working with my windows clients using SLAAC addressing.

2
  • Well Windows clients will actually try to update ip address via Dynamic DNS no matter if ip address is assigned via DHCPv6 or SLAAC. It is all a matter of if the DNS server allows update requests comming from the clients. – Lasse Michael Mølgaard Apr 18 '20 at 15:57
  • That's what would make sense to me too but not what was happening – Robert Meany Apr 18 '20 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.