• Promiscuous— A promiscuous port can communicate with all interfaces, including the isolated and community ports within a PVLAN.
• Isolated— An isolated port has complete Layer 2 separation from the other ports within the same PVLAN, but not from the promiscuous ports. PVLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic from an isolated port is forwarded only to promiscuous ports.
• Community— Community ports communicate among themselves and with promiscuous ports. These interfaces are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

IP Addressing
All the members of the Private VLAN can share a common IP Space where the IP space is assigned to the Primary VLAN. The hosts connected to isolated or community ports can have the addresses assigned from the address space of the Primary VLAN.

Steps to Configure Private VLAN

1. Set VTP mode to transparent
2. Create Primary and Secondary VLANs
3. Map secondary VLANs to Primary VLANs
3. Configure ports in Secondary VLANs and assign VLAN memberships
4. Configure Promiscuous ports and map them to primary-secondary VLAN pairs

Configuration:

Switches S1 and S2  must be configured as follows:

Create vlans 101 and 102 and then associate them to the primary Vlan 100.

vlan 100
  private-vlan primary
  private-vlan association 101-102
!
vlan 101
  private-vlan community
!
vlan 102
  private-vlan community

On S1:

interface FastEthernet0/1
 switchport private-vlan mapping 100 101-102
 switchport mode private-vlan promiscuous
!
interface FastEthernet0/3
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface FastEthernet0/5
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

On S2:
interface GigabitEthernet0/4
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface GigabitEthernet0/6
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface GigabitEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

If using a centralized system for user authentication, the router or switch would be an authentication client. It will need to communicate with a server using a specialized protocol. Two such protocols are wide known: TACACS, a Cisco proprietary protocol and RADIUS, an open standard protocol. In a Cisco-centered  network, IOS authentication would work with Cisco’s ACS (Access Control Server), but in some cases , specially for lab purposes, ACS could be harder to get an setup.

A very quick way to setup an authentication server is to use FreeRADIUS, an open source server that uses the RADIUS protocol. It can be easily installed on a Linux box and used with minimum configurations. Here are the steps to setup:

Install the packet:

root@radiusserver# apt-get install freeradius

Add each client (router or switch) in the /etc/freeradius/clients.conf file. Each client is identified by its hostname and requires a password (secret).

root@radiusserver# vim /etc/freeradius/clients.conf

Client 192.168.0.2
{
secret = authentications3cr3t
shortname = ClientRouter

}

Add each user that is allowed on the device.

root@radiusserver# vim /etc/freeradius/users.conf

iosuser Cleartext-Password := “icanhazroot”
DEFAULT Auth-Type := Reject

Start or restart the FreeRADIUS server:

root@radiusserver# /etc/init.d/freeradius restart

On the client side (the network device), AAA needs to be enabled, the RADIUS server configured and then the authentication need to be set to use an external server.

ClientRouter(config)# aaa new-model
ClientRouter(config)# radius-server host $RADIUS_SERVER_IP auth 1812 acct 1813 key authentications3cr3t
ClientRouter(config)# aaa authentication login default group radius

This is a basic configuration of a FreeRADIUS server, but it can also provide features like LDAP intergration.

Per-destination load balancing allows the router to use multiple paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. Traffic destined for different pairs tend to take different paths. Per-destination load balancing is enabled by default when you enable CEF.

To determine if CEF is enabled globally on a router, use the commands show ip cef and show ipv6 cef. If it is not enabled by default, you can turn it on globally using the command ip cef for IPv4. To enable CEF for IPv6, first enable CEF for IPv4, then use the command ipv6 cef. You can verify that CEF is enabled on an interface using the commands show cef interface {interface} and show ipv6 cef {interface} detail.

Topology

The routing table of router R2 is similar to R1:

R1#show ip route

[...]

C    192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
S       2.2.2.0 [1/0] via 192.168.21.2
[1/0] via 192.168.12.2
C    192.168.21.0/24 is directly connected, FastEthernet1/0

Check if CEF is enabled and show the forwarding information base (FIB) with information obtained from the routing table.

R1#show ip cef
Prefix                    Next Hop                    Interface
0.0.0.0/0           drop                              Null0 (default route handler entry)
0.0.0.0/32         receive
1.1.1.0/24           attached                      Loopback1
1.1.1.0/32           receive
1.1.1.1/32            receive
1.1.1.255/32       receive
2.2.2.0/24           192.168.21.2            FastEthernet1/0
192.168.12.2            FastEthernet0/0

[...]

Routers with default configuration perform Load Sharing per destination, also known as Fast Switching. Fast switching is the default IOS switching mode in some routers. The debug ip packet command displays process packets.

R1#debug ip packet
IP packet debugging is on
R1#ping 2.2.2.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
R1#
*Mar  1 00:39:40.379: IP: tableid=0, s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 00:39:40.379: IP: s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending
*Mar  1 00:39:40.431: IP: tableid=0, s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), routed via RIB
*Mar  1 00:39:40.431: IP: s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), len 100, rcvd 3
R1#ping 2.2.2.2 repeat 1 so
R1#ping 2.2.2.2 repeat 1 source loo 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
R1#
*Mar  1 00:39:48.411: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via FIB
*Mar  1 00:39:48.411: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar  1 00:39:48.467: IP: tableid=0, s=2.2.2.2 (FastEthernet1/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar  1 00:39:48.467: IP: s=2.2.2.2 (FastEthernet1/0), d=1.1.1.1, len 100, rcvd 4

Note that for different source-destination pairs the outbound interface changes.

Per packet Load Sharing configuration.

R1(config)#int f 0/0
R1(config-if)#no ip route-cache    //enable process switching
R1(config-if)#ip load-sharing per-packet
R1(config-if)#exit
R1(config)#int f 1/0
R1(config-if)#no ip route-cache
R1(config-if)#ip load-sharing per-packet
R1(config-if)#exit

R1#sh cef interface fastEthernet 0/0
[...]
Per packet load-sharing is enabled
[...]
Fast switching type 1, interface type 18
IP CEF switching disabled

Verify per packet Load Sharing:

R1#ping 2.2.2.2 source loopback 1 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/37/52 ms
R1#
*Mar  1 01:00:35.419: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 01:00:35.419: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending
!
*Mar  1 01:00:35.467: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via FIB
*Mar  1 01:00:35.467: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
!
*Mar  1 01:00:35.523: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 01:00:35.523: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending

When CEF is disabled all the packets are processed by the Routing Information Base (RIB) as shown below:

R1(config)#no ip cef
R1(config)#exit
R1#clear ip cef * prefix-statistics
R1#clear ip cef 2.2.2.2 prefix-statistics
R1#ping 2.2.2.2 source loopback 1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 28/56/84 ms
*Mar  1 01:07:07.475: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar  1 01:07:07.475: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
!
*Mar  1 01:07:07.507: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via RIB
*Mar  1 01:07:07.507: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending

The simple answer is to create a GRE tunnel between R1 and R3 so a tun interface simulates a direct connection of the two routers. But let’s take a more didactic approach to remember some things about RIP.

RIP v2 sends the updates to the address 224.0.0.9 that is a local multicast address (TTL=1).  But there is another, very important in some situations (like some Frame Relay networks), way to send routes, and that is via unicast to a statically configured neighbor. Configuration is done via the neighbor command in the router rip configuration.  The routes will be encapsulated in normal IP unicast packets and since RIP runs on top of UDP, they should be routed as any other packet.

R1:

interface Serial0/0/1
ip address 10.1.2.1 255.255.255.0
interface Loopback 0
ip address 192.168.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 192.168.0.0
neighbor 10.2.3.3
no auto-summary

R3:

interface Serial0/0/1
ip address 10.2.3.3 255.255.255.0
interface Loopback 0
ip address 172.16.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 172.16.0.0
neighbor 10.1.2.1
no auto-summary

You still need to have a network command for the interfaces when you send and receive the updates (in this case 10.0.0.0) otherwise the received updates will be ignored.

First thing you should be careful of is the fact that R1 and R3 need layer3 communication. So you do need static routes for the R1 and R3 routers through R2.

Having connectivity between each other, the router starts sending unicast packets with the routes. debug ip rip would show the following:

RIP: sending v2 update to 10.1.2.1 via Serial0/0/1 (10.2.3.3)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0

Notice the update is sent to an unicast address and not 224.0.0.9.

Routes are received but they still are not in the routing tables. debug ip rip shows why:

RIP: ignored v2 update from bad source 10.2.3.3 on Serial0/0/1

This reminds us of how RIP works: if a router receives an update it checks to see if the source of the packet is on the same subnet as the IP configured on the interface. If they don’t match, the update is ignored. In our case, the source of the updates are not on the same network because R2 does not modify the packet source/destination in any way.

The solution to this is to disable the default mechanism with the no validate-update-source command in the router rip configuration. This way any updates will be accepted.

Here is a wanted route in the routing table of R3:

R    192.168.0.0/24 [120/1] via 10.1.2.1, 00:00:27

Notice that the next hop is not directly connected so it need to do a recursive lookup and use the static route to send it to R2 first.

S       10.1.2.1/32 [1/0] via 10.2.3.2

Scenario:

The Host in the 192.168.0.0/24 network should get its IP address from a DHCP server.

Relay is the default router for the Host, but doesn’t have a DHCP service running. It will pass any DHCP requests from it’ f1/0 interface to the DHCP server that has DHCP pools configured on it, using the “ip helper-addres” command.

Between the DHCP router and the Relay router there is a public network, but behind Relay, there is a private network (Host is part of that network).  Relay will use NAT with overload (PAT) to service the private network.

Relay uses DHCP as it’s default route to the Internet, but DHCP doesn’t know about the private network in which Host is in (private networks shoudn’t be permitted to be accessed from the Internet).

Configurations:

DHCP:

ip dhcp pool DHCP_POOL
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1

interface FastEthernet0/0
ip address 200.0.0.1 255.255.255.0

Relay:

interface FastEthernet0/0
ip address 200.0.0.100 255.255.255.0
ip nat outside

interface FastEthernet1/0
ip address 192.168.0.1 255.255.255.0
ip helper-address 200.0.0.1
ip nat inside

ip nat inside source list NAT_HOSTS interface FastEthernet0/0 overload

ip access-list standard NAT_HOSTS
permit 192.168.0.0 0.0.0.255

Host:

interface FastEthernet1/0
ip address dhcp

Problem:

Relay will receive a DHCP request (broadcast) on F1/0 interface. Because of the “ip helper-address“, Relay will transform the request from broadcast to unicast and send it to the DHCP router. The  DHCP request will reach the router, it will assign  an IP from the pool, but the reply will never reach Host.

Explenation:

Using “debug ip dhcp server events“, “debug ip dhcp server packet” and “debug ip packet“, we can find out the problem.

The first thing that could come to mind is the fapt that if Relay receives a packet on F1/0 interface (192.168.0.1) it will send an unicast message with the source IP address of that interface and a destination address of the ip-helper server. This is not true. The relayed request is considered to be generated by the local router (Relay). This means that the source IP address of the relayed request is that of the outgoing interface to the DHCP Server. Here is the debug ip packet output:

*Mar  1 02:33:23.127: IP: tableid=0, s=200.0.0.100 (FastEthernet0/0), d=200.0.0. 1 (FastEthernet0/0), routed via RIB

If  the source address of the IP packet does not have an IP address from the 192.168.0.0/24 network, how does the DHCP Server know from witch pool to give out a free address. The answer is a field in the DHCP protocol, called GIADDR (Gateway IP Address). The value of this field will be the IP address of the interface in the private network.

The problem is that after the DHCP server chooses an IP from the pool, it will reply to the unicast request, with another unicast packet that has the destination IP the GIADDR, not the source address of the request. The output from debug ip dhcp server events:

*Mar  1 03:13:33.719: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d 63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 through relay 192.168.0.1.
*Mar  1 03:13:33.731: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 (192.168.0.2).
*Mar  1 03:13:33.731: DHCPD: unicasting BOOTREPLY for client cc02.05b0.0010 to relay 192.168.0.1

The DHCP router doesn’t know about the 192.168.0.0/24 network because that is a private network behind a NAT.

A solution to the situation is to add a static route on the DHCP router to the private network. But this would ruin the purpose of NAT. A better solution is to avoid the scenario by design (still, the situation could come up in lab environments and you should now know why it behaves the way it does)

If you are connected to the router via telnet or ssh (most likely in productions routers) it is very easy to lock yourself out of the router by denying the telnet or ssh traffic on an interface between you to that router. This is mostly because how IOS works. Any commands given in IOS are instantly commited to the live configuration. And, for example, if you make a configuration with an ACL and you forget about the implicit deny any (any) and you also forget to permit the telnet/ssh traffic, you might find yourself with the router not responding to any input after you apply the rules. It might take a while to figure out that you can’t access the router anymore and need to get physically to its location and either reload it or  use the console port to remove the ACL from the running-config.

One way of avoiding this is to schedule an automated reload in 10-15 minutes, while you are configuring, From enable mode issue the command:

#reload in MINUTES

This will reload the router after the specified number of minutes. It will ensure that if you lock yourself out, the router will revert back to the working startup-config. If the configuration was applied successfully, you can cancel the scheduled reload with the command

#reload cancel

Any lab with topologies that run different protocols over FR must start with the layer 2 configuration of the Frame Relay switched network. FR Topologies like full mesh or hub and spoke require a Frame Relay Switch. A FR Switch is a normal router but specifically configured to do Frame Relay switching.

First of all, we need to tell the router to start switching Frame Relay traffic. From global configuration mode we need to issue the frame-relay switching command.

Then, on the interfaces to Frame Relay clients, we need to start sending keepalives (LMIs) by configuring the interface as DCE with the frame-relay intf-type dce command.

The last thing that the FR Switch needs to do is to route DLCI on the virtual cicuits. This is done to tell an interface where to put a received frame with a DLCI. The frame will be put on another interface with another DLCI.  The configuration is done per interface with the frame-relay route command. The command requires that you specify the incoming  DLCI, on which the switching decision will be maide, the outgoing interface, and the DLCI with which the frame will be sent (”freame-relay route IN_DLCI OUT_INT OUT_DLCI”).

If Inverse ARP is not disabled on the FR Switch, no DLCI-IP mappings will be required.

Topology:

Configuration:

R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#encapsulation frame-relay
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0

R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0

FR-Sw(config)#frame-relay switching
FR-Sw(config)#int s0/1
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 102 interface s0/0 201
FR-Sw(config-if)#int s0/0
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 201 interface s0/1 102

Running Configurations:

R1:

interface Serial0/0
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

R2:

interface Serial0/0
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

FR-Sw:

interface Serial0/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay intf-type dce
frame-relay route 201 interface Serial0/1 102
end

interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0 201
end

In a back-to-back scenario is important to remember what the FR Switch should be doing: being the DCE and sending the keepalives to maintain the layer 2 link to the client router. Because of the fact that no FR Switch is present, the lack of keepalives being sent must be ignored using the “no keepalive” command. Also, Inverse ARP won’t work, so manual IP-DLCI mapping will be needed.

The FR Switch should be the one doing swapping of DLCIs on the network so the frames arrive at their destination with the correctly mapped DLCIs. In this case, we will need to have the same DLCI set in the manual mapping so the routers match entries in the mappings.

The topology:

Configuration:

R1(config)#int s0/1
R1(config-if)#no shut
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 10.1.2.2 42
R1(config-if)#no keepalive

R2(config)#int s0/1
R2(config-if)#no shut
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay map ip 10.1.2.1 42
R2(config-if)#no keepalive

Running configurations:

R1:

interface Serial0/1
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
no keepalive
clockrate 128000
frame-relay map ip 10.1.2.2 42
end

R2:

interface Serial0/1
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 10.1.2.1 42
end

The usual “show run” command prints a large output, from which you need only a few lines. You can only scroll down with space and enter (the the Linux more command). If you are searching for a keyword in the running config, you can go to the line that contains the string using the slash key, like in vim or more or less in Linux. So, “/KEYWORD” after running the show command, while scrolling, will take you to the wanted line.

If you want from the output just some lines, you can filter them, just like piping the output to grep in Linux. You can use the ” | ” after the show command to see how you can filter (be careful, there is a space before and after the |). To print just the lines that have a keywork, use “ | include KEYWORD“, and to print all lines except the ones what have the keyword, use “ | exclude KEYWORD“. If you want to print out all output starting with a line that contains a keyword until the end of the lines, use “ | begin KEYWORD“.

Taking advantage of the hierarchical structure of the running config, you can print out just a section of the output. For example, “show run | section   router ospf 1” will list the configuration for the OSPF process 1 and “show run | section interface Serial0/0” will print the configuration for the specified interface. Be careful, this is case sensitive and you need to mach the case of the line in the running config (”Serial 0/0″ will work, “serial 0/0″ won’t).

Redirection into a file is also possible. “show run | redirect flash:run” will put the contents of the running config into a file called ‘run’ in flash memory. This is similar to the “>” operand in Bash. Using redirect, the content of the target file will be replaced. You can append to the file (like “>>” in Bash) with “ | append FILE“.  “ | tee FILE” works like redirect, but it also prints the output to the screen.

Regular expressions are also supported. If you like to print from the routing table, the routes received from RIP, you can filter with “show ip route | include R” and the routes from EIGRP with  “show ip route | include D”. But you can do this in one line, filtering with both conditions, with “show ip route | include [RD]“.

Slightly off topic, but good to know, is how to stop output. For example, traceroute to an unreachable location, will try 30 hops before it stops, and this might take a long time. To break the action hit the key combination “Ctrl+Shift+6“.

Loopback 0 on R1 has the IP 2001:A::1/64 and Loopback 0 on R2 has the IP 2001:B::1/64.  We want to make R1 aware of the 2001:B::0/64 network and R2 aware of the 2001:A::0/64 network. RIPng would be the the easiest way of doing that.

First we need to enable IPv6 unicast routing, and then start the RIP process on the interfaces.

R1(config)#ipv6 unicast-routing
R1(config)#ipv6 router rip SIMPLE_RIP
R1(config)#interface lo0
R1(config-if)#ipv6 address 2001:A::1/64
R1(config-if)#ipv6 rip SIMPLE_RIP enable

R2(config)#ipv6 unicast-routing
R2(config)#ipv6 router rip SIMPLE_RIP
R2(config)#interface lo0
R2(config-if)#ipv6 address 2001:B::1/64
R2(config-if)#ipv6 rip SIMPLE_RIP enable

We also need to activate the RIP process on the transit link and make the interface IPv6 enabled.

R1(config)#interface s0/1/1

R1(config-if)#ipv6 rip SIMPLE_RIP enable

R1(config-if)#ipv6 enable

R2(config)#interface s0/1/1

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 rip SIMPLE_RIP enable

As it can be noticed, we haven’t configured a global IPv6 address on the interface, yet, RIP will do it’s job.

R2#sh ipv6 route
IPv6 Routing Table – 5 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
R   2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1
C   2001:B::/64 [0/0]
via ::, Loopback0
L   2001:B::1/128 [0/0]
via ::, Loopback0
L   FE80::/10 [0/0]
via ::, Null0
L   FF00::/8 [0/0]
via ::, Null0

The reason why it works, it’s a link local address, which is automatically configured once you turn on IPv6 on the interface. If the command “(config-if)#ipv6 enable” would have been missing, there would have been no exchange of routes.

Let us now analyze a possible misconfiguration. Let’s configure a global address on the link. What first comes to mind is IPv4 rule that stated that the serial interface of each router has to be configured in the same broadcast domain.  We will configure the serial interface on R1 with 2001:C::1/64 and serial interface on R2 with 2001:D::1/64 (clearly in different subnets).

R1#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:E8FF:FEF2:8F3A
No Virtual link-local address(es):
Global unicast address(es):
2001:C::1, subnet is 2001:C::/64

R2#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::21A:2FFF:FE2A:2118
No Virtual link-local address(es):
Global unicast address(es):
2001:D::1, subnet is 2001:D::/64

Even if we don’t have the two routers in the same subnet from the global address perspective, they are in the same broadcast domain from the link local address point of view. The traffic will still be routed via the link local address, because it’s actually “closer”.

R   2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1

So, if your routes are flowing when you are thinking that they shouldn’t, you might want to remember the link local address.

Thanks go out to BogdanD for help with case study.