Hello -

I've got RouterOS 3.24 on an RB1000 in a data center, doing IPv4 and v6 routing. The DC gave me a couple of /64's, one for the router and one for a client machine behind it (mine). I assigned my side of the /64 for the router to the router port that I am using for WAN, and set a route for outbound traffic, following the examples in this post: http://forum.mikrotik.com/viewtopic.php ... pv6#p93989. At this point I can ping from the router to publicly accessible IPv6 addresses, like the one for ipv6.google.com, etc. I added the second /64 to the interface (a VLAN) for my client machine behind the router, which has some statically configured IPs and a gateway from that range already set up on it (not using advertising for this). At this point, I have the following conditions:

1. I can ping the IPv6 client IPs on my client machine from the router;

2. The client IPv6 IPs on my machine can be pinged by Admins at the DC;

3. I can ping the IPv6 client IPs on my client machine from elsewhere on the internet (outside of the DC network);

4. I can ping the IPv6 cients IPs from on the machine that they are hosted on (self-ping);

5. I cannot ping out from the client box to any other IPv6 IP subnet, whether hosted elsewhere in my network, or out on the public internet (such as the IP for ipv6.google.com).

The client box does have a default route and gateway for the IPv6 subnet, and it was able to reach external IPv6 points with the same network settings before I put it behind the router. Any ideas?

Thanks!

Ed

LATER - Just performed a confirming test in cooperation with the DC NOC with the DC directly routing the /64 to the client box. Everything worked and and I could ping in and out, full accessibility. Put it back behind the router and routed the /64 back throught the router: I can ping in to the client box but cannot ping out. No changes to the config on the client box, the only change was having the DC route directly vs routing through the router. I've gone over my config on the router with the DC and they don't see any issues - anyone got any ideas out there?

Well, this has really generated a flurry of excitement on this board! I sure wish someone could help me with this. Is anyone out there using IPv6 in production in the data center, like I am trying to do, and is it working for them? I'll post the ipv6 config export below. One thing I did not note in my previous post: the client /64 is added to a VLAN which is bound to ether2. Here's the config:

# jun/03/2009 16:28:58 by RouterOS 3.24
# software id = TAZS-PTT
#
/ipv6 address
add address=2001:xxxxx::2/64 advertise=no disabled=no eui-64=no interface=\
ether1 ### this is the IP for the wan port of the router, the DC routes client /64s through this
add address=2001:yyy:y:yy::1/64 advertise=no disabled=no eui-64=no interface=\
client-1 ### this is the client /64, added to the client vlan, which does work (tested with IPv4)
/ipv6 nd
add advertise-dns=no advertise-mac-address=yes disabled=no hop-limit=\
unspecified interface=all managed-address-configuration=no mtu=\
unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m \
ra-lifetime=30m reachable-time=unspecified retransmit-interval=\
unspecified
/ipv6 nd prefix default
set autoconfig=yes on-link=yes preferred-lifetime=1w valid-lifetime=4w2d
/ipv6 route
add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=\
2001:xxxxx::1 scope=30 target-scope=10 ### this is the DC's side of the /64 for the router's WAN port

If anyone sees anything wrong, please post.

Thanks!

Ed

at quick glance that looks right. can you make it work without vlan ?

at quick glance that looks right. can you make it work without vlan ?

Yes, I can. Basically, the router takes all client traffic on the WAN port (ether1) and routes it to client VLANS configured on ether2, which goes out to a network of VLAN-segmented L2 switches. The way things are physically connected, I can have any client routed through the RB IP or bypass the RB, simply by having the DC make a change on their side (had to do it this way, because I am dropping this router into a live network and taking over routing from the DC). When they route the /64 in question through the RB, I have this problem. When they bypass it, IPv6 on that /64 works fine. The only change they are making is routing the /64 directly to my interface vs routing it to the IPv6 address of the router. IPv4 works fine in either case, so VLANs are set up correctly, and I have full IPv6 access on the router itself - it just does not work when I route a client /64 through the router to the client VLAN. I am perplexed.

i asked that because im wondering if its an MTU issue on the VLAN maybe. Or possibly ipv6 and vlan's don't mix / not implemented yet. Can you continue your testing but using the native ethernet port instead of a vlan?

i asked that because im wondering if its an MTU issue on the VLAN maybe. Or possibly ipv6 and vlan's don't mix / not implemented yet. Can you continue your testing but using the native ethernet port instead of a vlan?

I have been wondering about that myself: if it's a matter of IPv6 not working with VLANs on ROS yet. Unfortunately that's the only way I can do it - this is a production environment with many clients scattered around on a network of L2 switches and the client machines cannot be connected directly to the router in a non-VLAN'd way, so if that's the issue, the only answer for me is to have Miktotik fix it. I have opened a support ticket with them on this. I'd be much appreciative if they would chime in on this thread as well.

Do you have any suggestsions to try with regards to MTU?

Thanks,

Ed

Ok, after all that, this problem has nothing to do with ROS. The client machine had picked up an IPv6 address from a different subnet which was being advertised by the NOC - apparently the router was passing these advertisements to all interfaces. The client was using that address on outbound requests instead of one from it's own range, and of course the RB1000 was ignoring those packets because that address is not configured on the client's interface. Oops.

this is going to be one of the most common problems as i see it. 128 bits of addressing is confusing to look at and determine whats in the same subnet. It's not nearly as clear cut as 32 bit : )