This topic is to discuss the following lesson:
Hello,
I hope you’re doing very well?
I want to know [EUI/CAL/PRE] what does it mean please?
Cheers,
Ulrich
1 Like
Hello Djan
These acronyms display several attributes of the IPv6 address, and are always displayed after the address itself. These are part of the output of the show ipv6 interface command. Specifically, the [EUI/CAL/PRE] acronyms you mention are indicating that:
EUI - Extended Unique Identifier. The address was generated using EUI-64, a method by which the IPv6 address is derived from the MAC address of the interface.
CAL - Calendar. This means that the address is timed and has valid and preferred lifetimes.
PRE - Preferred. This timed address is preferred.
There are several other attributes as well and you can find them at this Cisco Command Reference link for the show ipv6 interface command.
I hope this has been helpful!
Laz
So although that example works well, its missing one more component to test both your example and my need… You need a router “beyond” the ISP router to insure you can reach the hosts from an extended “ISP” network.
I’ve been trying to do the same thing in your example, however with a “remote” KEA DHCP server (v1.5.0) server from ISC. Issuing the PD is not an issue. What I’ve been having problems with is that the router that is issuing the PD for whatever reason (labeled ISP in your example) is not putting the route in its local routing table (for redistribution into OSPFv3, etc) so I cannot reach the prefixes that were issued to the client.
Specifically, the configuration I’m using on the PE router to the customer is:
service dhcp ipv6 unicast-routing ! interface GigabitEthernet0/1.101 encapsulation dot1Q 101 ipv6 address FE80::101:1 link-local ipv6 address 2600:2100:122:1::1/64 ipv6 enable ipv6 nd prefix 2600:2100:122:1::/64 no-advertise ipv6 nd managed-config-flag ipv6 nd router-preference High ipv6 dhcp relay destination 2600:2100::FEED:1 ospfv3 10 ipv6 area 0
Where 2600:2100::FEED:1 is my kea-dhpc6 server (can issue both stateful information as well as PDs). The kea server currently issues /60 and /56 blocks as requested.
Note: The prefix no-advertise combined with the nd managed-config-flag forces the client to get a DHCP issued address and that using SLAAC will not work for them (since manage-config-flag is only a suggestion, we pull the prefix to force the issue).
So although the client picks up the PD, and correctly uses it itself, the PE router that the route was issued through doesn’t seem to pick up on the fact that a PD was issued (contrary to all the cisco documentation I’ve been reading). Specifically, its supposed to insert into its local routing table a static route to the PD via the IPv6 address that made the PD request. From there, I could then redistribute that into my OSPF tables as an E2 route. I’m currently using IOS 15.2(4) on the PE device.
Hello Marcos
I don’t have a clear cut answer for you at the moment, however, doing some research, I’ve found the following Cisco documentation.
https://www.cisco.com/c/en/us/td/docs/routers/asr903/software/guide/ip/16-6-1/b-dhcp-xe-16-6-asr900/implementing_dhcp_for_ipv6.html#GUID-82004112-75D9-4114-A19C-B0B8B75DC21B
Now I know that you yourself have gone through documentation as well, however, if I may add the following comments, it may steer you in the right direction.
Among other useful information in this section, it states that:
IPv6 routes are added when the relay agent relays a RELAY-REPLY packet, and IPv6 routes are deleted when the prefix delegation lease time expires or the relay agent receives a release message. An IPv6 static route in the routing table of the relay agent can be updated when the prefix delegation lease time is extended.
Could it be that the KEA DHCP server is sending this RELAY-REPLY packet but it is not being perceived by the Cisco router? Is the DHCP server configured appropriately to have this packet sent in order for the relay agent to insert the appropriate routes to the destinations assigned this prefix? More generally, what I’m saying is, is there a possibility that the DHCP server being used may require some additinoal configuration in order for it to communicate correctly with the Cisco router. Can you attempt the same topology, but instead, use a Cisco router as your DHCP server and see if that allows the relay agent to install the appropriate routes?
I hope this brings you one step closer to the solution! Try it out and let us know…
I hope this has been helpful!
Laz
Hi REne and staff,
thanks for your work (it is not pretented)
i lab this lesson with
and i test some other prefix values for the global pool
When the global pool is /40 (like in the lesson) the delegation is between 40 and 56
when the global pool is /32 the delegation is between 32 and 48
it seems that the upper value is + 16
And you cannot use a value greater than the upper value (when /32 the upper value is /48 and you cannot use /56 for example)
Is there a reason for that ?
Regards
Hello Dominique
This is an interesting limitation. Looking at the Cisco command reference this keyword is called the assigned-length. For the assigned-length, it states the following:
Length of prefix, in bits, assigned to the user from the pool. The value of the assigned-length argument cannot be less than the value of the / prefix-length argument.
It makes sense that the assigned value cannot be less than the value of the prefix of the address space defined by the command. However, it doesn’t mention an upper limit. Indeed, in the example configuration it has the following:
Router (config)# ipv6 local pool pool1 2001:0DB8::/29 64
It shows here that the assigned-length is 64 while the prefix length is 29, which does not conform to the limitation you stated. I have also tried to lab up the specific feature, and I too have the same limitation as you.
It would seem that this 16 bit limitation matches up with the default subnet sizes found in the IPv6 Global Unicast Subnet Assignments as stated in the following lesson:
The lesson states that the subnets that can be assigned to customers are 16 bits in length.
This of course is just by definition, you are able to change this in your own IPv6 allocation, but if you’re going to conform to the way global unicast IPv6 addresses are being distributed worldwide, this is the standard that is being used.
The only thing I can suggest is that the IOS or platform (at least the ones we are using) are conforming to this. Other IOS/platform combinations may not have this limitation, as is indicated by the command reference.
I hope this has been helpful!
Laz
Hi, we used C1(config-if)#ipv6 address ISP_PREFIX ::1:0:0:0:1/64 command. I didn’t get what is the use of ::1:0:0:0:1/64 …
Hello Mohanad
If you look at the configuration of the Gi0/1 interface of C1, you will see that it has been configured as a DHCP client. This DHCP client stores the prefix received from the ISP as ISP_PREFIX. Specifically, the prefix that C1 will receive will be 2001:DB8:1100::/48 and this is the value stored. Note that this value indicates a 48-bit prefix of an IPv6 address.
Now when Gi0/2 is configured using an IPv6 address, the following command is used:
C1(config-if)#ipv6 address ISP_PREFIX ::1:0:0:0:1/64
What this command is saying essentially is assign an IPv6 address to this interface that uses the prefix stored in ISP_PREFIX and adds the host portion of ::1:0:0:0:1/64. Immediately after this command if you issued the show ipv6 interface brief command, you should see that the Gi0/2 interface has been assigned the 2001:DB8:1100:1:0:0:0:1 address which is simply a concatenation of the prefix stored in ISP_PREFIX and the host portion explicitly stated in the command.
I hope this has been helpful!
Laz
1 Like
Something to add here. The above works with an ASR 1001 running 3.16 or later. But it doesn’t work on a Cisco 7301 running 15.2(4). Documentation on the 7301 states that you need to add to the global configuration “ipv6 dhcp iapd-route-add” in order to add in the PD routes sent via the DHCP6 server.
Unfortunately my 7301 running 15.2(4) doesn’t seem to have that command and I cannot find a reference about what version of IOS it was introduced or if its a service provider only command. I was reading the documentation on the 7301 and the command is in the documentation, just not on the router itself… I’m running the following image as well (c7301-adventerprisek9-mz.152-4.M11.bin)
Clues?
Hello Marcos
As is usually the case, there are features and commands that are available on some platform/IOS combinations and not on others. This depends upon what Cisco decides to include in each version.
As for the ipv6 dhcp iapd-route-add command, from what I’ve seen, this is enabled by default, at least on the ASR platforms, but again, this depends upon the platform.
In order for us to help you more effectively, can you share with us the specific commands from the lesson that are not working for you on the 7301 platform?
I hope this has been helpful!
Laz
So now I’m dealing with this PD issue on more than one platform. With the ASR1001, 1001x, 1002, the prefix delegation and route insertion are working “natively” on 3.16 and later versions (I haven’t tester on many earlier versions as I haven’t felt the need). I just did a deployment on a Nexus 7k and discovered that it is NOT putting the PD into the routing tables just like the Cisco 7301 didn’t. Now I’m trying to track this one down.
For background, I’m working at an ISP where our customers home routers constantly ask for prefix-delegations for the households. Since this might be 200-300 home routers on a network, trying to put these prefix’s in statically is a non-started for obvious reasons. Currently we are running ISC’s KEA server (1.8.4) to do our prefix delegations and we’ve tested with /64, /60, and /56 delegations. As you pointed out, the router is supposed to watch for the RELAY-REPLY packet and in the case of the ASRs, seems to be doing fine.
To some degree, even though I have around 50 or so C7301’s in the field, I’ve sort of given up on making them work and those customers are basically out of luck in terms of IPv6 until those routers are upgraded (unfortunately your talking years). But we do have some major sites and towers off of our N7K platform and it not doing prefix-delegation is a bigger problem (replacing c7301s over time is dooable, replacing the N7K is non-trivial/expensive/hard to think about).
With that said, do you have any pointers or suggestions on PD under IPv6 on the N7K platform? Currently we’re running NXOS 6.2(24)
Hello Marcos
We’d like to create a testbed with a Nexus device to replicate your situation. From my understanding, your Nexus 7k is the PE, correct? You’ve mentioned several different devices and I’m not clear on what role each one plays. Can you share with us a simplified topology and where the N7K fits in so we can attempt to replicate it?
Thanks!
Laz
Sure, it will take me awhile to draw something simple out (I don’t have a nice drawing program that produces simple drawings like you have on here. Pointers on that welcome).
Basically in some of the larger points-of-presence we have 7009 switches (dual SUP-2E) doing very basic routing, DHCP forwarding, etc. Not at all using the N7K’s for what they were designed, but its hard to beat the secondary market price on these considering all our links to residential and business customers are all 1G links. Currently we are running an old (6.2) version of the NXOS but are starting to experiment in the lab with 7.3. Upgrading to 7.3 in the field will be a huge challenge for us however so its a less desirable route.
Basically at the end of our wireless network (large scale L2 network, typically anywhere from 30-500 customers per L2 network) is one of three devices, a C7301, an ASR1001x, or an N7K. Lots of details on how that actually works however. So in this particular case, the VLAN that makes up the N7K interface (see above configuration) is where we are delegating the PD from our KEA server however the N7K isn’t recognizing the PD assignment so its not creating a “route” to the device through the customer router.
Hello Marcos
Thanks for the details. I’ll get this to @ReneMolenaar Rene and see if we can spend a little bit of time labbing this up just to see what can be done. Hope to get back to you soon!
Laz
Hello Marcos
After spending some time with @ReneMolenaar labbing this up, we too were unable to get it to work as expected. It seems that PD is something that the Nexus devices were not particularly designed to do. Keep in mind that Nexus switches are designed particularly for the datacenter, and IPv6 PD is not something you would often see in a DC.
Things to keep in mind:
- There is little to no documentation about IPv6 PD for Nexus devices. It seems like its not in their feature set, but there is no documentation that explicitly states this.
- The NX-OS version you are using is considered end of support and end of life, you may want to consider upgrading the NX-IOS if the platform supports it.
- We labbed it up using real 5K devices as well as CML 9K devices, but we had the same results.
Now one of the additional points that we found is that prefix delegation does operate in conjunction with a DHCPv6 relay agent using a relay agent notification for PD. More about that for IOS devices here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-sy/dhcp-15-sy-book/ip6-dhcp-rel-agent.html#GUID-52D23F09-6829-4950-9431-92D9B7A255C0
Based on this, one question that did come up is what is your configuration? Are you using a relay agent in your nexus? Can you share with us a sanitized version of your config in the Nexus so that we can take a closer look?
I hope this has been helpful!
Laz