In this post, we’re going to walk through the process for configuring RIPng on Junos-based devices. It is very similar to RIP, so you may like to look at configuring RIP part 1 and part 2 as well.
RIPng is used to advertise IPv6 routes. So we will want to look at the inet6.0 routing table as we progress through the steps below.
There are a couple of key points to remember:
- RIPng configuration uses groups
- We specify what interfaces to run RIPng on
- The default import policy for RIPng is to import all RIPng routes
- The default export policy for RIPng is to reject all routes, including those learned via RIPng. We will need to add a policy to advertise RIPng routes.
Lab Setup
The following diagram details the lab.
A couple of things to note with the lab:
- A mix of vSRX, vMX, and vQFX devices are used. This is done solely to show that the configuration is the same across devices.
- The addressing in use, 2001:db8::/32 is the IPv6 documentation range. See this APNIC post and this RFC for reference.
- Each device has a loopback address in the 2001:db8::.x range, where x is the router number.
- Each vSRX has been put into packet mode, so it will act as a router.
- This is done with the ‘set security forwarding-options family mpls mode packet-based’ and ‘set security forwarding-options family inet6 mode packet-based’ command. You may need to delete the security policies stanza for this to commit. Depending on the version you may also need to reboot the device for packet mode to take effect.
RIPng Configuration
Router R1
We will configure the following:
- Interfaces
- RIPng protocol with one group
- Routing policy to advertise both direct and RIPng routes
There are a couple of things worth noting with the below configuration.
- When specifying the IP Address for loopback 0 (lo0), a mask of /128 is assumed unless you specify otherwise.
- When configuring the neighbors under RIPng we specify the interfaces in two different ways. For the first interface, we do not specify the logical unit, so Junos assumes we mean unit 0. For the second interface, we do specify the logical unit, which in this case is 0 anyway. This is important when dealing with interfaces with multiple logical units.
lab@vsrx-R1> edit
Entering configuration mode
[edit]
lab@vsrx-R1# set interfaces lo0 unit 0 family inet6 address 2001:db8::1
[edit]
lab@vsrx-R1# set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:100:1::1/64
[edit]
lab@vsrx-R1# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:100:3::1/64
[edit]
lab@vsrx-R1# set policy-options policy-statement my-ripng-export term export-rip-and-direct from protocol direct
[edit]
lab@vsrx-R1# set policy-options policy-statement my-ripng-export term export-rip-and-direct from protocol ripng
[edit]
lab@vsrx-R1# set policy-options policy-statement my-ripng-export term export-rip-and-direct then accept
[edit]
lab@vsrx-R1# set protocols ripng group my-ripng-group1 neighbor ge-0/0/0
[edit]
lab@vsrx-R1# set protocols ripng group my-ripng-group1 neighbor ge-0/0/1.0
[edit]
lab@vsrx-R1# set protocols ripng group my-ripng-group1 export my-ripng-export
[edit]
lab@vsrx-R1# show | compare
[edit interfaces ge-0/0/0 unit 0]
+ family inet6 {
+ address 2001:db8:100:1::1/64;
+ }
[edit interfaces ge-0/0/1 unit 0]
+ family inet6 {
+ address 2001:db8:100:3::1/64;
+ }
[edit interfaces lo0 unit 0]
+ family inet6 {
+ address 2001:db8::1/128;
+ }
[edit policy-options]
+ policy-statement my-ripng-export {
+ term export-rip-and-direct {
+ from protocol [ direct ripng ];
+ then accept;
+ }
+ }
[edit]
+ protocols {
+ ripng {
+ group my-ripng-group1 {
+ export my-ripng-export;
+ neighbor ge-0/0/0.0;
+ neighbor ge-0/0/1.0;
+ }
+ }
+ }
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1>Router R2
We will configure the following:
- Interfaces
- RIPng protocol with one group
- Routing policy to advertise both direct and RIPng routes
{master:0}
lab@vqfx-R2> edit
Entering configuration mode
{master:0}[edit]
lab@vqfx-R2# set interfaces lo0 unit 0 family inet6 address 2001:db8::2
{master:0}[edit]
lab@vqfx-R2# set interfaces xe-0/0/0 unit 0 family inet6 address 2001:db8:100:1::2/64
{master:0}[edit]
lab@vqfx-R2# set interfaces xe-0/0/1 unit 0 family inet6 address 2001:db8:100:2::1/64
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-ripng-export term export-rip-and-direct from protocol direct
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-ripng-export term export-rip-and-direct from protocol ripng
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-ripng-export term export-rip-and-direct then accept
{master:0}[edit]
lab@vqfx-R2# set protocols ripng group my-ripng-group1 neighbor xe-0/0/0
{master:0}[edit]
lab@vqfx-R2# set protocols ripng group my-ripng-group1 neighbor xe-0/0/1
{master:0}[edit]
lab@vqfx-R2# set protocols ripng group my-ripng-group1 export my-ripng-export
{master:0}[edit]
lab@vqfx-R2# show | compare
[edit interfaces xe-0/0/0 unit 0]
+ family inet6 {
+ address 2001:db8:100:1::2/64;
+ }
[edit interfaces xe-0/0/1 unit 0]
+ family inet6 {
+ address 2001:db8:100:2::1/64;
+ }
[edit interfaces lo0 unit 0]
+ family inet6 {
+ address 2001:db8::2/128;
+ }
[edit policy-options]
+ policy-statement my-ripng-export {
+ term export-rip-and-direct {
+ from protocol [ direct ripng ];
+ then accept;
+ }
+ }
[edit protocols]
+ ripng {
+ group my-ripng-group1 {
+ export my-ripng-export;
+ neighbor xe-0/0/0.0;
+ neighbor xe-0/0/1.0;
+ }
+ }
{master:0}[edit]
lab@vqfx-R2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@vqfx-R2>Now that we have at least two routers configured, we can do a quick check to ensure things are working as expected. First, we can check RIPng neighbors.
{master:0}
lab@vqfx-R2> show ripng neighbor
Source Dest In
Neighbor State Address Address Send Recv Met
-------- ----- ------- ------- ---- ---- ---
xe-0/0/0.0 Up fe80::205:86ff:fed0:1503 ff02::9 yes yes 1
xe-0/0/1.0 Up fe80::205:86ff:fed0:1507 ff02::9 yes yes 1
{master:0}
lab@vqfx-R2>The output for this command is a bit misleading. The ‘Local State’ Field is only talking about the state of the interface. It does not mean that we have a neighbor on that interface. At this stage, we haven’t configured R3 yet, so R2 can’t have a neighbor on interface xe-0/0/1.0.
The other difference that we can start to see is the addresses mentioned. Those are not the addresses we configured on the interfaces, instead, they are the link-local addresses for the interfaces.
If we look at the RIPng statistics it looks similar to the RIP output. It is a bit shorter as there is no version 1 and version 2 to differentiate between like there is with RIP.
{master:0}
lab@vqfx-R2> show ripng statistics
RIPng info: port 521; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
3 0 0 0
xe-0/0/0.0: 3 routes learned; 3 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 9 8 2
Triggered Updates Sent 1 1 0
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 9 9 2
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 0 0 0
RIPng Requests Ignored 0 0 0
xe-0/0/1.0: 0 routes learned; 5 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 9 8 2
Triggered Updates Sent 2 2 0
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 0 0 0
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 0 0 0
RIPng Requests Ignored 0 0 0
{master:0}
lab@vqfx-R2>We can also check what RIP routes we have learned. Notice the next hop addresses. Again, they are the link-local addresses and not the addresses we configured. The routes are held in the inet6.0 routing table, which is the IPv6 routing table on Junos.
{master:0}
lab@vqfx-R2> show route protocol ripng
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
inet6.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::1/128 *[RIPng/100] 00:06:10, metric 2, tag 0
> to fe80::5200:ff:fe01:1 via xe-0/0/0.0
2001:db8:100:1::/64 [RIPng/100] 00:06:10, metric 2, tag 0
> to fe80::5200:ff:fe01:1 via xe-0/0/0.0
2001:db8:100:3::/64*[RIPng/100] 00:06:10, metric 2, tag 0
> to fe80::5200:ff:fe01:1 via xe-0/0/0.0
ff02::9/128 *[RIPng/100] 00:06:23, metric 1
MultiRecv
{master:0}
lab@vqfx-R2>Since we can see a route for R1’s loopback, we can move on with the other devices.
Router R3
We will configure the following:
- Interfaces
- RIPng protocol with one group
- Routing policy to advertise both direct and RIPng routes
Since R3 is almost the same as R1, I’ll just show the ‘show | compare’ output.
[edit]
lab@vsrx-R3# show | compare
[edit interfaces ge-0/0/0 unit 0]
+ family inet6 {
+ address 2001:db8:100:2::2/64;
+ }
[edit interfaces ge-0/0/1 unit 0]
+ family inet6 {
+ address 2001:db8:100:4::1/64;
+ }
[edit interfaces lo0 unit 0]
+ family inet6 {
+ address 2001:db8::3/128;
+ }
[edit policy-options]
+ policy-statement my-ripng-export {
+ term export-rip-and-direct {
+ from protocol [ direct ripng ];
+ then accept;
+ }
+ }
[edit]
+ protocols {
+ ripng {
+ group my-ripng-group1 {
+ export my-ripng-export;
+ neighbor ge-0/0/0.0;
+ neighbor ge-0/0/1.0;
+ }
+ }
+ }
[edit]
lab@vsrx-R3#Router R4 and R5
Since the configuration is almost the same as the other devices, I’ll just show the ‘show | compare’ before the commit.
[edit]
lab@vmx-R4# show | compare
[edit interfaces ge-0/0/0 unit 0]
+ family inet6 {
+ address 2001:db8:100:5::1/64;
+ }
[edit interfaces ge-0/0/1 unit 0]
+ family inet6 {
+ address 2001:db8:100:3::2/64;
+ }
[edit interfaces lo0 unit 0]
+ family inet6 {
+ address 2001:db8::4/128;
+ }
[edit policy-options]
+ policy-statement my-ripng-export {
+ term export-rip-and-direct {
+ from protocol [ direct ripng ];
+ then accept;
+ }
+ }
[edit protocols]
+ ripng {
+ group my-ripng-group1 {
+ export my-ripng-export;
+ neighbor ge-0/0/0.0;
+ neighbor ge-0/0/1.0;
+ }
+ }
[edit]
lab@vmx-R4#Router R5
[edit]
lab@vmx-R5# show | compare
[edit interfaces ge-0/0/0 unit 0]
+ family inet6 {
+ address 2001:db8:100:5::2/64;
+ }
[edit interfaces ge-0/0/1 unit 0]
+ family inet6 {
+ address 2001:db8:100:4::2/64;
+ }
[edit interfaces lo0 unit 0]
+ family inet6 {
+ address 2001:db8::5/128;
+ }
[edit policy-options]
+ policy-statement my-ripng-export {
+ term export-rip-and-direct {
+ from protocol [ direct ripng ];
+ then accept;
+ }
+ }
[edit protocols]
+ ripng {
+ group my-ripng-group1 {
+ export my-ripng-export;
+ neighbor ge-0/0/0.0;
+ neighbor ge-0/0/1.0;
+ }
+ }
[edit]
lab@vmx-R5#Verifying RIPng Operation
The commands for RIPng are all very similar to those we used for RIP.
The following looks at R1 in particular.
We can look at RIPng neighbors and RIPng statistics.
With the statistics, we are mainly looking for the updates sent and received counters to increment over time.
lab@vsrx-R1> show ripng neighbor
Source Dest In
Neighbor State Address Address Send Recv Met
-------- ----- ------- ------- ---- ---- ---
ge-0/0/0.0 Up fe80::5200:ff:fe01:1 ff02::9 yes yes 1
ge-0/0/1.0 Up fe80::5200:ff:fe01:2 ff02::9 yes yes 1
lab@vsrx-R1> show ripng statistics
RIPng info: port 521; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
8 0 0 0
ge-0/0/0.0: 6 routes learned; 4 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 429 10 2
Triggered Updates Sent 3 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 418 10 2
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 1 0 0
RIPng Requests Ignored 0 0 0
ge-0/0/1.0: 2 routes learned; 8 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 429 11 2
Triggered Updates Sent 5 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 378 10 2
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 1 0 0
RIPng Requests Ignored 0 0 0
lab@vsrx-R1>We can look at the routing table. Since we are only interested in RIPng routes, we can specify that with the show route command. We should see all the link nets and the loopback addresses of the other routers.
lab@vsrx-R1> show route protocol ripng
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
inet6.0: 16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[RIPng/100] 03:17:39, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::3/128 *[RIPng/100] 03:05:25, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::4/128 *[RIPng/100] 02:59:50, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8::5/128 *[RIPng/100] 02:57:58, metric 4, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:1::/64 [RIPng/100] 03:17:39, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:2::/64*[RIPng/100] 03:17:39, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:3::/64 [RIPng/100] 02:59:50, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:4::/64*[RIPng/100] 03:05:20, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
ff02::9/128 *[RIPng/100] 03:24:49, metric 1
MultiRecv
lab@vsrx-R1>There are a few things worth noting from the above output.
We have a route for ff02::0/128. That is so we can receive the RIPng updates that are multicasted to that address.
As noted earlier the next hops are all link local addresses.
To further prove our routing is working, we can ping from the loopback of R1 to the loopback of R3 like so:
lab@vsrx-R1> ping 2001:db8::3 source 2001:db8::1 count 5
PING6(56=40+8+8 bytes) 2001:db8::1 --> 2001:db8::3
16 bytes from 2001:db8::3, icmp_seq=0 hlim=63 time=107.588 ms
16 bytes from 2001:db8::3, icmp_seq=1 hlim=63 time=106.900 ms
16 bytes from 2001:db8::3, icmp_seq=2 hlim=63 time=108.603 ms
16 bytes from 2001:db8::3, icmp_seq=3 hlim=63 time=106.473 ms
16 bytes from 2001:db8::3, icmp_seq=4 hlim=63 time=113.429 ms
--- 2001:db8::3 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 106.473/108.599/113.429/2.520 ms
lab@vsrx-R1>
Finally, we can show what routes we are sending to or receiving from a particular neighbor.
To see what routes we are receiving, we specify the neighbor who is sending the updates to us. This will again need to be the link-local address. To find this, I used the next-hop information from the show route command.
lab@vsrx-R1> show route receive-protocol ripng fe80::205:86ff:fed0:1503
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
inet6.0: 16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[RIPng/100] 03:21:47, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::3/128 *[RIPng/100] 03:09:33, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::5/128 *[RIPng/100] 03:02:06, metric 4, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:1::/64 [RIPng/100] 03:21:47, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:2::/64*[RIPng/100] 03:21:47, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:4::/64*[RIPng/100] 03:09:28, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
lab@vsrx-R1>To show what routes we are advertising, we specify our own link-local address of the interface we advertise the updates out of. We can find this with a show interface terse command.
lab@vsrx-R1> show interfaces ge-0/0/0 terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.100.1.1/24
inet6 2001:db8:100:1::1/64
fe80::5200:ff:fe01:1/64
lab@vsrx-R1> show route advertising-protocol ripng fe80::5200:ff:fe01:1
inet6.0: 16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::1/128 *[Direct/0] 03:30:18
> via lo0.0
2001:db8::4/128 *[RIPng/100] 03:05:19, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:1::/64*[Direct/0] 03:30:07
> via ge-0/0/0.0
[RIPng/100] 03:23:08, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:3::/64*[Direct/0] 03:30:07
> via ge-0/0/1.0
[RIPng/100] 03:05:19, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
lab@vsrx-R1>Similar to RIP, this might seem a bit confusing at first. RIPng doesn’t establish neighbors or adjacencies. We could receive updates from multiple routers on a single interface, and the updates we send on an interface could reach several different routers.
Because of this, when looking at received routes, we need to specify which router the update came from. When looking at what routes we are advertising, we need to specify the address of the interface we are sending the update out.
RIPng and Routing Instances
Just like with RIP, we can configure RIPng under a routing instance.
We can modify R5 to show this in action. We create a new routing instance of type virtual-router and put the relevant interfaces into the routing instance. We then add RIPng. It looks like this:
routing-instances {
my-routing-instance {
protocols {
ripng {
group my-group-1 {
export my-ripng-export;
neighbor ge-0/0/0.0;
neighbor ge-0/0/1.0;
}
}
}
instance-type virtual-router;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.0;
}
}We can run the same show commands as before, but we need to add the ‘instance’ option and specify what routing instance we want to look at.
lab@vmx-R5> show ripng neighbor instance my-routing-instance
Source Dest In
Neighbor State Address Address Send Recv Met
-------- ----- ------- ------- ---- ---- ---
ge-0/0/0.0 Up fe80::5200:ff:fe06:2 ff02::9 yes yes 1
ge-0/0/1.0 Up fe80::5200:ff:fe06:3 ff02::9 yes yes 1
lab@vmx-R5> show ripng statistics instance my-routing-instance
RIPng info: port 521; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
9 4 0 0
ge-0/0/0.0: 5 routes learned; 10 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 1 0 0
Triggered Updates Sent 3 1 1
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 2 0 0
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 1 0 0
RIPng Requests Ignored 0 0 0
ge-0/0/1.0: 5 routes learned; 6 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 5 4 2
Triggered Updates Sent 3 1 0
Responses Sent 0 0 0
Bad Messages 0 0 0
Updates Received 7 5 3
Bad Route Entries 0 0 0
Updates Ignored 0 0 0
RIPng Requests Received 0 0 0
RIPng Requests Ignored 0 0 0
lab@vmx-R5>To view the routing table for our routing instance, we can either run a ‘show route’ and look through the output for the table we want, or specify the table in the show route command. In this case, the table is my-routing-instance.inet6.0
lab@vmx-R5> show route table my-routing-instance.inet6.0
my-routing-instance.inet6.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::1/128 *[RIPng/100] 00:01:17, metric 3, tag 0
> to fe80::5200:ff:fe05:2 via ge-0/0/0.0
2001:db8::2/128 *[RIPng/100] 00:03:17, metric 3, tag 0
> to fe80::5200:ff:fe02:2 via ge-0/0/1.0
2001:db8::3/128 *[RIPng/100] 00:03:17, metric 2, tag 0
> to fe80::5200:ff:fe02:2 via ge-0/0/1.0
2001:db8::4/128 *[RIPng/100] 00:01:17, metric 2, tag 0
> to fe80::5200:ff:fe05:2 via ge-0/0/0.0
2001:db8::5/128 *[Direct/0] 00:03:28
> via lo0.0
2001:db8:100:1::/64*[RIPng/100] 00:01:17, metric 3, tag 0
> to fe80::5200:ff:fe05:2 via ge-0/0/0.0
to fe80::5200:ff:fe02:2 via ge-0/0/1.0
2001:db8:100:2::/64*[RIPng/100] 00:03:17, metric 2, tag 0
> to fe80::5200:ff:fe02:2 via ge-0/0/1.0
2001:db8:100:3::/64*[RIPng/100] 00:01:17, metric 2, tag 0
> to fe80::5200:ff:fe05:2 via ge-0/0/0.0
2001:db8:100:4::/64*[Direct/0] 00:03:17
> via ge-0/0/1.0
[RIPng/100] 00:03:17, metric 2, tag 0
> to fe80::5200:ff:fe02:2 via ge-0/0/1.0
2001:db8:100:4::2/128
*[Local/0] 00:03:17
Local via ge-0/0/1.0
2001:db8:100:5::/64*[Direct/0] 00:01:30
> via ge-0/0/0.0
[RIPng/100] 00:01:17, metric 2, tag 0
> to fe80::5200:ff:fe05:2 via ge-0/0/0.0
2001:db8:100:5::2/128
*[Local/0] 00:01:30
Local via ge-0/0/0.0
fe80::5200:f:fc08:0/128
*[Direct/0] 00:03:28
> via lo0.0
fe80::5200:ff:fe06:2/128
*[Local/0] 00:01:30
Local via ge-0/0/0.0
fe80::5200:ff:fe06:3/128
*[Local/0] 00:03:17
Local via ge-0/0/1.0
ff02::2/128 *[INET6/0] 00:03:29
MultiRecv
ff02::9/128 *[RIPng/100] 00:03:29, metric 1
MultiRecv
lab@vmx-R5>Changing A Metric
With our current lab setup, when we ping from R1 to the loopback of R3, the path will be via R2.
We can prove this with a traceroute.
lab@vsrx-R1> show route protocol ripng
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
inet6.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[RIPng/100] 03:37:56, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::3/128 *[RIPng/100] 03:25:42, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8::4/128 *[RIPng/100] 03:20:07, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8::5/128 *[RIPng/100] 00:04:28, metric 3, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:1::/64 [RIPng/100] 03:37:56, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:2::/64*[RIPng/100] 03:37:56, metric 2, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:3::/64 [RIPng/100] 03:20:07, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:4::/64*[RIPng/100] 00:04:28, metric 3, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:5::/64*[RIPng/100] 00:04:28, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
ff02::9/128 *[RIPng/100] 03:45:06, metric 1
MultiRecv
lab@vsrx-R1> traceroute 2001:db8::3 source 2001:db8::1
traceroute6 to 2001:db8::3 (2001:db8::3) from 2001:db8::1, 64 hops max, 12 byte packets
1 2001:db8:100:1::2 (2001:db8:100:1::2) 106.009 ms 200.724 ms 202.050 ms
2 2001:db8::3 (2001:db8::3) 202.022 ms 202.087 ms 204.032 ms
lab@vsrx-R1>The route to 2001:db8::3 has a metric of 3 and passes through R2. But what if we want to change that? On R1 we can adjust the metric added to incoming routes on interface ge-0/0/0.0.
lab@vsrx-R1> edit
Entering configuration mode
[edit]
lab@vsrx-R1# set protocols ripng group my-ripng-group1 neighbor ge-0/0/0 metric-in 5
[edit]
lab@vsrx-R1# show protocols ripng
group my-ripng-group1 {
export my-ripng-export;
neighbor ge-0/0/0.0 {
metric-in 5;
}
neighbor ge-0/0/1.0;
}
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1>Below you can see the route to 2001:db8::3 is now preferring to go via R4 and R5.
lab@vsrx-R1> show route protocol ripng
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
inet6.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[RIPng/100] 00:00:11, metric 5, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8::3/128 *[RIPng/100] 00:00:11, metric 4, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8::4/128 *[RIPng/100] 03:23:39, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8::5/128 *[RIPng/100] 00:08:00, metric 3, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:1::/64 [RIPng/100] 00:00:22, metric 6, tag 0
> to fe80::205:86ff:fed0:1503 via ge-0/0/0.0
2001:db8:100:2::/64*[RIPng/100] 00:00:14, metric 4, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:3::/64 [RIPng/100] 03:23:39, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:4::/64*[RIPng/100] 00:00:22, metric 3, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
2001:db8:100:5::/64*[RIPng/100] 00:08:00, metric 2, tag 0
> to fe80::5200:ff:fe05:3 via ge-0/0/1.0
ff02::9/128 *[RIPng/100] 00:00:42, metric 1
MultiRecv
lab@vsrx-R1> traceroute 2001:db8::3 source 2001:db8::1
traceroute6 to 2001:db8::3 (2001:db8::3) from 2001:db8::1, 64 hops max, 12 byte packets
1 2001:db8:100:3::2 (2001:db8:100:3::2) 6.937 ms 2.170 ms 3.564 ms
2 2001:db8:100:5::2 (2001:db8:100:5::2) 15.359 ms 5.534 ms 4.512 ms
3 2001:db8::3 (2001:db8::3) 10.880 ms 102.768 ms 105.301 ms
lab@vsrx-R1>Conclusions.
RIPng configuration and verification is almost exactly like RIP. Everywhere you see rip, you replace it with ripng and it’s pretty much good to go.
There is a difference with the next hops, where RIPng is using the link-local address.
If you haven’t already, check out part 2 of configuring RIP. That covered a few topics not discussed here such as authentication and using policy to adjust metrics. The difference for RIPng should only be what addresses, if any, you specify in the policy.