This topic is to discuss the following lesson:
awesome lesson. just a question rene, when we activate the RIP under the interface it does 2 things
Activate the prefix on the interface in RIPNG.
Send RIPNG updates out of this interface.
do we have a passive interface on this? is this the same as RIP or any routing protocol in IPv4 that if the interface is going to your LAN network, it is much better not to Send Routing updates to that interface. We suppressed it by using Passive Interface so that we will only advertise the network on that interface. This is for security purposes right?
Good question, the behavior of RIPng is the same as RIP for IPv4. The funny part though is that there is no “passive interface” command for RIPng.
To simulate the same behavior of the passive interface command you can use one of the following two methods:
Don’t enable RIPng on the interface that should be made passive but use “redistribute connect” instead.
Use a prefix-list to filter RIPng advertisements on the interface that should be passive.
It’s a bit lame and I don’t know why passive interface isn’t supported, but this gets you the same result
Just a question, more of a general IPV6 question, why does a loopback interface generate the same link-local address as the physical interface. Yes I understand that the loopback don’t have it’s own mac address and will use the physical interface, but why doesn’t it cause a conflict on the local device, I was under the impression the link-local address must be unique on the llocal device:
R8#sh ipv6 int brief Em0/0 [administratively down/down] unassigned GigabitEthernet0/0 [up/up] FE80::6273:5CFF:FEF8:D8E0 GigabitEthernet0/1 [up/up] unassigned Serial0/0/0 [down/down] unassigned Loopback0 [up/up] FE80::6273:5CFF:FEF8:D8E0 2001:DB8::1
These link-local addresses are only valid on the link and unroutable so that’s why it is no problem to have the same address on multiple interfaces.
Is it possible to work with summarized routes in the dynamic routing protocol, as well as in static routing?
Routing protocols, including RIPNG, support summarization yes.
Here’s how you can do summarization in RIPNG. Right now, R2 only has one entry:
R2#show ipv6 route rip R 2001::1/128 [120/2] via FE80::F816:3EFF:FE30:91B8, FastEthernet0/0
Summaries are configured on the interface in RIPNG. Let’s try that on R1:
R1(config)#interface GigabitEthernet 0/1 R1(config-if)#ipv6 rip RIPNGTEST summary-address 2001::/64
Here’s the result:
R2#show ipv6 route rip R 2001::/64 [120/2] via FE80::F816:3EFF:FE30:91B8, FastEthernet0/0 R 2001::1/128 [120/2] via FE80::F816:3EFF:FE30:91B8, FastEthernet0/0
You can see the 2001::/64 summary route on R2.
With a static route, we don’t advertise anything so there’s no summary route like in routing protocols.
Just wondering what if I manually set different link-local address on the different interface in a router when setup RIPNG, is there any error message popup?
If you manually set up different link-local addresses on the interfaces of a router, even if you have RIPNG set up, there shouldn’t be any error messages. This is especially the case with RIPNG because you don’t have any network commands to indicate the subnet on which RIP will be participating. You specifiy the interface on which RIP will be function and this allows you to change the IPv6 address (link local or otherwise) without any problems on your configuration).
I hope this has been helpful!
how can I to activate RIPng on subinterfaces? or what is the best way ?
You can enable RIPng on subinterfaces in the same way that you enable it on physical interfaces. Just remember that the
ipv6 rip RIPNGTEST enable command should be implemented on the subinterface, and not on the physical interface. Beyond that there really isn’t any special configs you require.
I hope this has been helpful!
Hi Rene/Laz and Team,
In regards to the link local address which has been assigned to the loopback interfaces in the example - Is this just a virtual MAC address which will be the same for all loopback interfaces on the device?
Also, how was the loopback interface assigned a link local address without the ipv6 enable command being issued?
Your assistance would be greatly appreciated
Thanks for your support!
The link local address is an IPv6 address that is automatically assigned to all IPv6 interfaces. It is a fundamental part of how IPv6 functions. You can find out more about it at this lesson:
The link-local address is assigned using various mechanisms, and those mechanisms depend on the vendor of the equipment or the operating system being used. Specifically, Cisco uses the EUI-64 method to determine the link-local address.
Now you bring up a very good point, because loopbacks don’t actually have a MAC address, not even a virtual one, so the EUI-64 method will not work directly. When you enable IPv6 on a loopback interface, it will actually “borrow” a MAC address from another interface and use it to determine its link local address. This isn’t actually a problem, because link local addresses must be unique on each network segment. In fact, you can have the same link local address on all of your routed interfaces on a network device without any problem.
ipv6 enable command is only needed if you want to enable IPv6 on an interface that has not been configured with an IPv6 global unicast address. When an interface is explicitly configured with an IPv6 global unicast address, it automatically becomes IPv6 enabled, and there is no need to issue the
ipv6 enable command. Interestingly, if you issue the
no ipv6 enable command on an interface with a configured IPv6 address, the command would be ignored. Notice in the lesson, that the 2001::1 and 2001::2 addresses have been assigned to the loopbacks, so the
ipv6 enable command is not necessary.
I hope this has been helpful!
Thank you for the very informative response this is much appreciated! Also some nice facts regarding the IPV6 enable command