This topic is to discuss the following lesson:
I hope you’re doing very well?
I want to know [EUI/CAL/PRE] what does it mean please?
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!
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.
I don’t have a clear cut answer for you at the moment, however, doing some research, I’ve found the following Cisco documentation.
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!
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 ?
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!