Basic RIPng Configuration

Basic RIPng Configuration

Two routers R2 and R3 are connected to each other via their Fastethernet interfaces. R3 also has a Loopback0 interface.

To enable RIPng, no global configuration is required. However, to include commands that would affect the complete RIPng configuration like timers, default-route origination, maximum-paths, etc, they must be put under RIPng router configuration mode. Also note, multiple RIPng processes can be run on a single router.

The ipv6 address eui-64 command assigns an IPv6 address to the interface with interface identifier i.e. the EUI-64 format interface identifier in the lower-order 64-bits.

R2# show ipv6 interface brief

FastEthernet0/0 [up/up]

FE80::D202:14FF:FE70:0

2001:ABAB::D202:14FF:FE70:0

R3# show ipv6 interface brief

FastEthernet0/0 [up/up]

FE80::D203:14FF:FE70:0

2002:ABAB::D203:14FF:FE70:0

Loopback0 [up/up]

FE80::D203:14FF:FE70:0

2003:ABAB::D203:14FF:FE70:0

NOTE: The IP addresses of R2's and R3's fastethernet interfaces does not belong to the same subnet since it is not a requirement in IPv6 routing.

As soon as the interface fastethernet 0/0 is UP and enabled for RIPng, it requests triggered updates from its neighbors and starts sending RIPng updates to multicast address FF02::9 and source address as its link-local address, and source and destination port 521. It includes the prefix of the interfaces for which RIPng is enabled. Here, debug ipv6 rip output is taken from R2 router.

*Mar 1 00:05:35.263: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Mar 1 00:05:35.275: RIPng: Link-local FE80::D203:12FF:FEF0:0/10 added

*Mar 1 00:05:35.275: RIPng: Full advertisement required

*Mar 1 00:05:35.279: RIPng: Sending multicast update on FastEthernet0/0 for RIP

*Mar 1 00:05:35.279: src=FE80::D203:12FF:FEF0:0

*Mar 1 00:05:35.279: dst=FF02::9 (FastEthernet0/0)

*Mar 1 00:05:35.279: sport=521, dport=521, length=32

*Mar 1 00:05:35.279: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:05:35.279: tag=0, metric=1, prefix=2001:ABAB::/64

R2#

*Mar 1 00:05:35.287: RIPng: Sending multicast request on FastEthernet0/0 for RIP

*Mar 1 00:05:35.287: src=FE80::D203:12FF:FEF0:0

*Mar 1 00:05:35.291: dst=FF02::9 (FastEthernet0/0)

*Mar 1 00:05:35.291: sport=521, dport=521, length=32

*Mar 1 00:05:35.291: command=1, version=1, mbz=0, #rte=1

*Mar 1 00:05:35.291: tag=0, metric=16, prefix=::/0

*Mar 1 00:05:35.291: RIPng: Triggered update requested, in hold-down

*Mar 1 00:05:36.263: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

R2 continues to send periodic updates to multicast address FF02::9 every 30 seconds.

R2#

*Mar 1 00:06:04.171: RIPng: Sending multicast update on FastEthernet0/0 for RIP

*Mar 1 00:06:04.171: src=FE80::D203:12FF:FEF0:0

*Mar 1 00:06:04.171: dst=FF02::9 (FastEthernet0/0)

*Mar 1 00:06:04.171: sport=521, dport=521, length=32

*Mar 1 00:06:04.175: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:06:04.175: tag=0, metric=1, prefix=2001:ABAB::/64

When R3 router's fastethernet 0/0 interface is enabled for RIPng, it responds to R2 router's request messages.

R2#

*Mar 1 00:07:42.527: RIPng: response received from FE80::D204:12FF:FEF0:0 on FastEthernet0/0 for RIP

*Mar 1 00:07:42.531: src=FE80::D204:12FF:FEF0:0 (FastEthernet0/0)

*Mar 1 00:07:42.531: dst=FF02::9

*Mar 1 00:07:42.531: sport=521, dport=521, length=32

*Mar 1 00:07:42.531: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:07:42.535: tag=0, metric=1, prefix=2002:ABAB::/64

*Mar 1 00:07:42.535: RIPng: Added neighbor FE80::D204:12FF:FEF0:0/FastEthernet0/0

*Mar 1 00:07:42.535: RIPng: Inserted 2002:ABAB::/64, nexthop FE80::D204:12FF:FEF0:0, metric 2, tag 0

*Mar 1 00:07:42.535: RIPng: RIPv6 ager started, 180000

When R3 router's Loopback0 interface is also enabled for RIPng, another update message is sent by R3 router.

R2#

*Mar 1 00:07:58.367: RIPng: response received from FE80::D204:12FF:FEF0:0 on FastEthernet0/0 for RIP

*Mar 1 00:07:58.371: src=FE80::D204:12FF:FEF0:0 (FastEthernet0/0)

*Mar 1 00:07:58.371: dst=FF02::9

*Mar 1 00:07:58.371: sport=521, dport=521, length=32

*Mar 1 00:07:58.371: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:07:58.371: tag=0, metric=1, prefix=2003:ABAB::/64

*Mar 1 00:07:58.375: RIPng: Inserted 2003:ABAB::/64, nexthop FE80::D204:12FF:FEF0:0, metric 2, tag 0

*Mar 1 00:07:58.375: RIPng: Triggered update requested, in hold-down

As seen above, R2 installs both prefixes 2002:ABAB::/64 and 2003:ABAB::/64 in its routing table with next-hop as R3 router's fastethernet 0/0 link-local address. Also, R3 router advertises both prefixes with metric 1, however, R2 router installs them with metric 2 indicating it takes him metric 1 to reach to R3 router.

R3 router also continues to send periodic updates every 30 seconds to all its interfaces, including Loopback 0, with all its RIPng enabled prefixes.

R3#

*Mar 1 00:04:21.995: RIPng: Sending multicast update on Loopback0 for RIP

*Mar 1 00:04:21.995: src=FE80::D203:14FF:FE70:0

*Mar 1 00:04:21.995: dst=FF02::9 (Loopback0)

*Mar 1 00:04:21.999: sport=521, dport=521, length=72

*Mar 1 00:04:21.999: command=2, version=1, mbz=0, #rte=3

*Mar 1 00:04:21.999: tag=0, metric=1, prefix=2002:ABAB::/64

*Mar 1 00:04:21.999: tag=0, metric=1, prefix=2003:ABAB::/64

*Mar 1 00:04:21.999: tag=0, metric=2, prefix=2001:ABAB::/64

*Mar 1 00:04:22.003: RIPng: Sending multicast update on FastEthernet0/0 for RIP

*Mar 1 00:04:22.003: src=FE80::D203:14FF:FE70:0

*Mar 1 00:04:22.003: dst=FF02::9 (FastEthernet0/0)

*Mar 1 00:04:22.007: sport=521, dport=521, length=52

*Mar 1 00:04:22.007: command=2, version=1, mbz=0, #rte=2

*Mar 1 00:04:22.007: tag=0, metric=1, prefix=2002:ABAB::/64

*Mar 1 00:04:22.007: tag=0, metric=1, prefix=2003:ABAB::/64

*Mar 1 00:04:22.011: RIPng: Process RIP received own response on Loopback0

When R3 router's Loopback0 interface is shut down manually, R3 tries to send a final update to Loopback 0 interface with metric 16 and then updates its neighbors with a single RTE containing Loopback0 prefix with metric 16.

R3(config)# interface Loopback 0

R3(config-if)# shutdown

*Mar 1 00:05:05.407: RIPng: Loopback0 down

*Mar 1 00:05:05.411: RIPng: Sending final update on Loopback0 for RIP

*Mar 1 00:05:05.411: src=FE80::D203:14FF:FE70:0

*Mar 1 00:05:05.411: dst=FF02::9 (Loopback0)

*Mar 1 00:05:05.411: sport=521, dport=521, length=72

*Mar 1 00:05:05.415: command=2, version=1, mbz=0, #rte=3

*Mar 1 00:05:05.415: tag=0, metric=16, prefix=2001:ABAB::/64

*Mar 1 00:05:05.415: tag=0, metric=16, prefix=2002:ABAB::/64

*Mar 1 00:05:05.415: tag=0, metric=16, prefix=2003:ABAB::/64

*Mar 1 00:05:05.423: RIPng: Triggered update requested

R3#

*Mar 1 00:05:05.427: RIPng: Link-local FE80::D203:14FF:FE70:0/10 deleted

*Mar 1 00:05:05.431: RIPng: IDB down, 2003:ABAB::D203:14FF:FE70:0/64

*Mar 1 00:05:05.435: RIPng: Inserted 2003:ABAB::/64, nexthop ::, metric 16, tag 0

*Mar 1 00:05:05.435: RIPng: Triggered update requested, delaying

*Mar 1 00:05:05.439: RIPng: Process RIP received own response on Loopback0

*Mar 1 00:05:06.423: RIPng: generating triggered update for RIP

*Mar 1 00:05:06.423: RIPng: Sending multicast update on FastEthernet0/0 for RIP

*Mar 1 00:05:06.423: src=FE80::D203:14FF:FE70:0

*Mar 1 00:05:06.423: dst=FF02::9 (FastEthernet0/0)

*Mar 1 00:05:06.427: sport=521, dport=521, length=32

*Mar 1 00:05:06.427: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:05:06.427: tag=0, metric=16, prefix=2003:ABAB::/64

R2 router receives this update for R3 router's Loopback 0 and immediately generates a triggered update for its neighbors. It also initiates the garbage-collection-timer of 120 seconds since the holddown timer is set to 0 seconds by default.

*Mar 1 00:26:54.551: RIPng: response received from FE80::D203:14FF:FE70:0 on FastEthernet0/0 for RIP

*Mar 1 00:26:54.555: src=FE80::D203:14FF:FE70:0 (FastEthernet0/0)

*Mar 1 00:26:54.555: dst=FF02::9

*Mar 1 00:26:54.555: sport=521, dport=521, length=32

*Mar 1 00:26:54.555: command=2, version=1, mbz=0, #rte=1

*Mar 1 00:26:54.555: tag=0, metric=16, prefix=2003:ABAB::/64

*Mar 1 00:26:54.559: RIPng: 2003:ABAB::/64, path FE80::D203:14FF:FE70:0/FastEthernet0/0 unreachable

*Mar 1 00:26:54.559: RIPng: 2003:ABAB::/64, expired, ttg is 120

*Mar 1 00:26:54.559: RIPng: Triggered update requested

R2#

*Mar 1 00:26:55.559: RIPng: generating triggered update for RIP

*Mar 1 00:26:55.559: RIPng: Suppressed null multicast update on FastEthernet0/0 for RIP

R2#

*Mar 1 00:27:07.299: RIPng: response received from FE80::D203:14FF:FE70:0 on FastEthernet0/0 for RIP

*Mar 1 00:27:07.299: src=FE80::D203:14FF:FE70:0 (FastEthernet0/0)

*Mar 1 00:27:07.299: dst=FF02::9

*Mar 1 00:27:07.303: sport=521, dport=521, length=52

*Mar 1 00:27:07.303: command=2, version=1, mbz=0, #rte=2

*Mar 1 00:27:07.303: tag=0, metric=1, prefix=2002:ABAB::/64

*Mar 1 00:27:07.303: tag=0, metric=16, prefix=2003:ABAB::/64

After 120 seconds (garbage-collection-timer), R2 router deletes the prefix from its database.

R2#

*Mar 1 00:28:54.559: RIPng: Deleting 2003:ABAB::/64

The RIPng database can be viewed using show ipv6 rip RIP database command on R2 and R3 routers.

R2# show ipv6 rip RIP database

RIP process "RIP", local RIB

2002:ABAB::/64, metric 2, installed

FastEthernet0/0/FE80::D203:14FF:FE70:0, expires in 169 secs

2003:ABAB::/64, metric 2, installed

FastEthernet0/0/FE80::D203:14FF:FE70:0, expires in 169 secs

The RIPng timers related information can be viewed using show ipv6 rip command.

R2# show ipv6 rip

RIP process "RIP", port 521, multicast-group FF02::9, pid 153

Administrative distance is 120. Maximum paths is 3

Updates every 30 seconds, expire after 180

Holddown lasts 0 seconds, garbage collect after 120

Split horizon is on; poison reverse is off

Default routes are not generated

Periodic updates 63, trigger updates 12

Interfaces:

FastEthernet0/0

Redistribution:

None

Updates timer is the periodic update timer. Expire timer is the time in which updates expire. It is reinitialized to 180 whenever an update is received. Holddown timer is the time for which a router will not accept any new updates for the router. It is set to 0 by default. Garbage collect timer is set to 120 seconds by default. It is the time during which the route will be continued to advertise but if no updates are received, the route will be removed from the database.

It is very interesting to see that during holddown timer, a router will not accept any updates from its neighbor for that prefix. Once the holddown timer expires and new update is received for the route as reachable, it is immediately placed into the routing table. However, if the new update still indicates that the route is unreachable, the route is deleted from the database when the garbage collection timer expires which starts with the holddown timer.