IOS 12.2(33)SXI2a ipv6 nd prefix command

[laloperez]

Hi!

I've encountered a problem trying to configure something like this in a Sup720 with IOS 12.2(33)SXI2a:

router(config-if)#ipv6 address 2001:DB8:CAFE:CAFE::1/56

router(config-if)#ipv6 nd prefix 2001:DB8:CAFE:CAFE::/64

so the idea is to have a routed /56 for an interface, but a /64 for autoconfiguration of host interfaces. I've tried this first in a 12.2(31)SGA1, and it worked, but int the sup720 it renders an error:

%VlanXX: Error: 2001:DB8:CAFE:CAFE::/64 is overlapping with 2001:DB8:CAFE:CAFE::1/56. This error didn't appear in the 12.2(31)SGA1, and, in fact, we could route with any of the addresses in the range /56 configured in a server's interface, but at the same time, get one from autoconfig with a /64.

So, am I doing anything wrong, or is this the normal behaviour of the nd prefix command? If so, what's then its purpouse?

Thanks in advance,

[Calin C.]

The truth is that they are overlapping, and maybe SUP720 expect these networks to be different.

I've put together a test environment, but with C3745 (I didn't had the C65K to test) and add your configuration. No error message and everything is working fine.

Also I couldn't find anything on Internet regarding your error. So, my advice is that if this error doesn't bother too much and everything is working fine, just live with it. An alternative solution is to try with different subnets if you have.

HTH,

Calin

[laloperez]

Thank you for your efforts. The fact is that this behavior really annoys me, because I expected it to work like in the 4948s and I've planned with it in mind, only to discover this "feature" on the 6500.

Given that your test worked fine in a 3745, I presume this is a platform specific limitation. Maybe because of the ipv6 support in hardware of the C6500?

Nevertheless, I think that, given that in ipv6 you can put as many addresses on an interface as you want, from the same subnet or not, one of the uses of the should be precisely to permit to define a /64 for SLAAC in the network hosts, and at the same time permit to use manual addresses outside that prefix, should them to be in the range defined in the interface address configuration, as I did in my example.

Nobody really tried this in a 6500? Wow, I'm a pioneer xDD

Thanks again.

[Ole Troan · Accepted solution]

What you are seeing is not platform dependent. These changes should be integrated in all current / future versions of IOS on all platforms.

Then you can argue if this is the correct behaviour or not. The "ipv6 address" command really does two things. It configures an address on the interface and it is a short-hand to configure the on-link prefix on a link. The on-link prefix / "connected route in cisco speak" is used to determine for which destinations to do address resolution. The prefix will be advertised in RAs, but most IPv6 host implementations will ignore any prefix with a length different from /64. These hosts will then have a different view of what is considered on-link than what the router has.

What are you trying to achieve? Would a simple static route work equally well?

cheers,

Ole

[laloperez]

Hi, Ole,

the reason for doing it this way is that if I configure a /56 in the interface and announce a /64 with nd prefix, I can have SLAAC working and a lot less manual static routes defined for the other /64s. Let me try to explain:

I have about 200 servers in a VLAN, each one belonging to one client. I want each customer to have its own /64 in order for him to define addressing to its needs i.e. be capable of assigning one address to each web service he could be running, if he wants, or for https, etc. I want, too, the servers to have a SLAAC address under our control, so we need it to be a /64. But we don't want to define a /64 in the interface and have to statically route another 200 /64 more.

If we define a /56, we have 256 /64s available, routed directly through this /56, and we avoid the static routes. With a working nd prefix of /64, we can get the SLAAC at the same time, and we are happy

Another plus will be if the router wouldn't announce anything else than a /64 when configured in the interface. This will get rid of the kernel messages in Linux and others complaining of wrong SLAAC advertisements.

Hope this clarifies this issue. And thank you very much for the answer.

[Ole Troan]

OK, I think I understand what you want to do.

The /64 that each server uses is manually configured, right?

And each server is trusted so there is no issue of one hijacking someone elses prefix?

Then on the router instead of doing dynamic routing or something similar, you want to do address resolution for the whole /56.

Then you could do:

interface Ethernet0/0

ipv6 address 2001:db8::1/64

!

ipv6 route 2001:db8::/56

That is one static route for the whole VLAN. You don't get superfluos PIO options in the RAs (that you could turn off with the 'no-advertise' keyword) and you should get address resolution for the whole /56.

Best regards,

Ole

[laloperez]

Well, maybe I didn't explain it very well. In fact, it's the opposite that you comment: what we want is the servers to get an auto /64 address from the same /64. Then each customer can assign statically any address they want to their server from a different /64 for each customer. All these /64 belonging to the same /56 that we configure in the vlan interface, dynamically routed through OSPF. This way, we have not to configure any static address.

I admit that for this to be secured we need something like RA Guard and IPv6 PACL in the access switches, which the Cat2960 we use for the servers doesn't have available yet. We trust someday they will get the funtionality.

This is an example of the configs:

interface Vlan59

ipv6 address 2A02:BE8:2:1000::2/56

ipv6 enable

ipv6 traffic-filter PRUEBAS-IPV6 out

ipv6 nd prefix 2A02:BE8:2:1000::/64

ipv6 ospf 1 area 0

In the server:

eth0      Link encap:Ethernet  HWaddr 00:1e:c9:bb:ca:36 

          inet6 addr: 2a02:be8:2:1001::65/64 Scope:Global ----> manual

          inet6 addr: 2a02:be8:2:1001::66/64 Scope:Global ----> manual

          inet6 addr: 2a02:be8:2:1001::67/64 Scope:Global ----> manual

          inet6 addr: 2a02:be8:2:1001::1254/64 Scope:Global ----> manual

          inet6 addr: 2a02:be8:2:1000:21e:c9ff:febb:ca36/64 Scope:Global ----> SLAAC

          inet6 addr: fe80::21e:c9ff:febb:ca36/64 Scope:Link

Best regards,

[Ole Troan]

1. If the servers use OSPF to advertise each individual /64 to the router, then you don't need the /56. Perhaps only a /56 to Null0.
2. If you require the router to use address resolution to reach the servers, then my suggested configuration with the single static route does that. i.e. consider the /56 as onlink.

Which of the two is correct?

cheers,

Ole

[laloperez]

Hi, and sorry for the delay. Local holidays here.

About your questions:

1.- No, we are not doing OSPF in the servers. The router announces the /56 through OSPF. Servers know nothing about routing.

2.- That's correct, but having to define 250 static routes (well, in the worst case) per VLAN it's a bit time consuming and error prone, we suspect. That's why we like the behaviour of the "nd prefix" command as in the 4948 platform. What the trend is? to implement the command as it is in the 4948 and other platforms as the 37xx, or to go the 6500's way?

Best regards,

[Ole Troan]

Why isn't a single static route enough?

"ipv6 route 2001:db8::/56 Ethernet0/0"

cheers,

Ole

[laloperez]

Yes, it works, just it is not as "elegant" as doing it all in the interface config, and not having to redistribute the static in OSPF. Just an opinion. I like more the nd prefix solution.

Anyway, know something on how this issue is going to be dealt with in next IOS updates?

Regards, and thank you for your time,