Hello,
I'm writing this blog post because of 2 reasons:
The reason for rib-group is when you have more than one customer in your infrastructure and you divide logically the traffic (routing) so that one logical entity (customer) does not have access to the others entities (customers). But there are some cases when you want to share some of the applications between customers.
First, RIB = routing information base = routing table.
The rib-group feature is used to import routes into the routing table or export routes out of the routing table (default routing table or non-default routing table).
RIB groups allow you to redirect incoming routing information to a different routing table on the device. You can also install routing information into multiple routing tables simultaneously (more on this in the practical example).
OK. Now let's create a simple topology. Here you go:
So this is the topology, but let's make some changes to be more clear:
I hope this is more clear now. Let me explain:
Between router R1, R2 and R3 there is a "router on a stick" configuration. I've created the VLAN 10, VLAN 172 and VLAN 192, one for every customer to have a clear routing path. And because I will configure a virtual routing instance type (similar to vrf) there will be a complete isolation between the customers.
Now let's look at the configuration of router R1:
rokk@R1> show configuration | display set | no-more set version 14.1R1.10set system host-name R1set system root-authentication encrypted-password "$1$bMF3smWb$uDXn91gyB6J9cJ2FYu56Q."set system login user admin uid 2000set system login user admin class super-userset system login user admin authentication encrypted-password "$1$OUFAeSiu$/2miGlGHTPzKT8g3ssZVZ/"set system login user rokk uid 2001set system login user rokk class super-userset system login user rokk authentication encrypted-password "$1$Apro5K8R$FHKeID3dcr2l5xvu8fJV71"set system syslog user * any emergencyset system syslog file messages any noticeset system syslog file messages authorization infoset system syslog file interactive-commands interactive-commands anyIf you see, there is only the hostname set and a few users. Now let's look at the routing table:
rokk@R1> show route rokk@R1> Nothing. Why? Because for the moment there is not a single interface configured with and IP on it. But let's do this now:
set interfaces ge-0/0/0 description "Link to R2 ge-0/0/0"set interfaces ge-0/0/0 vlan-taggingset interfaces ge-0/0/0 unit 10 vlan-id 10set interfaces ge-0/0/0 unit 10 family inet address 10.0.12.1/30set interfaces ge-0/0/0 unit 172 vlan-id 172set interfaces ge-0/0/0 unit 172 family inet address 172.16.12.1/30set interfaces ge-0/0/0 unit 192 vlan-id 192set interfaces ge-0/0/0 unit 192 family inet address 192.168.12.1/30set interfaces ge-0/0/1 description "Link to R4 e0/0"set interfaces ge-0/0/1 unit 0 family inet address 10.0.14.1/30set interfaces ge-0/0/2 description "Link to R7 e0/0"set interfaces ge-0/0/2 unit 0 family inet address 192.168.17.1/30set interfaces lo0 unit 0 family inet address 172.16.1.1/32This is for now just the candidate configuration, until I commit the configuration it's just standing here:
rokk@R1# show | compare | no-more [edit]+ interfaces {+ ge-0/0/0 {+ description "Link to R2 ge-0/0/0";+ vlan-tagging;+ unit 10 {+ vlan-id 10;+ family inet {+ address 10.0.12.1/30;+ }+ }+ unit 172 {+ vlan-id 172;+ family inet {+ address 172.16.12.1/30;+ }+ }+ unit 192 {+ vlan-id 192;+ family inet {+ address 192.168.12.1/30;+ }+ }+ }+ ge-0/0/1 {+ description "Link to R4 e0/0";+ unit 0 {+ family inet {+ address 10.0.14.1/30;+ }+ }+ }+ ge-0/0/2 {+ description "Link to R7 e0/0";+ unit 0 {+ family inet {+ address 192.168.17.1/30;+ }+ }+ }+ lo0 {+ unit 0 {+ family inet {+ address 172.16.1.1/32;+ }+ }+ }+ }Now, by default if you set an IP on an interface and the interface it's physically UP, the there will be created automatic (it will be imported into the routing table) a local route and a direct route for every IP on the interface. Local means the IP configured on the interface and direct means that the subnet on which the local IP belongs is reachable on trough that interface. Now let's commit the configuration and take a look at the routing table:
[edit]rokk@R1# commit and-quit commit completeExiting configuration moderokk@R1> show route | no-more inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.0.12.0/30 *[Direct/0] 00:00:05 > via ge-0/0/0.1010.0.12.1/32 *[Local/0] 00:00:05 Local via ge-0/0/0.1010.0.14.0/30 *[Direct/0] 00:00:05 > via ge-0/0/1.010.0.14.1/32 *[Local/0] 00:00:05 Local via ge-0/0/1.0172.16.1.1/32 *[Direct/0] 00:00:05 > via lo0.0172.16.12.0/30 *[Direct/0] 00:00:05 > via ge-0/0/0.172172.16.12.1/32 *[Local/0] 00:00:05 Local via ge-0/0/0.172192.168.12.0/30 *[Direct/0] 00:00:05 > via ge-0/0/0.192192.168.12.1/32 *[Local/0] 00:00:05 Local via ge-0/0/0.192192.168.17.0/30 *[Direct/0] 00:00:05 > via ge-0/0/2.0192.168.17.1/32 *[Local/0] 00:00:05 Local via ge-0/0/2.0If you can see, everything belongs to the master (default) routing table inet.0 and this is because there is no other routing instance configured on the router.
Ok. Now let's create the two routing instances as virtual-router type and assigns the corresponding interfaces to each of the instance. Remember that by default all interfaces belong to the master routing instance and if there are remaining interfaces that will be not configured in a specific routing instance, those will remain in the master routing instance.
Also, as mentioned before, between R1, R2 and R3 there is a "router on a stick" configuration to have a logical interface for each of the instance: Interface ge-0/0/0.10 will be used for Customer A, interface ge-0/0/0.192 will be used for Customer C and interface ge-0/0/0.172 will be used for the master routing instance. Now let's see the configuration:
set routing-instances CUSTOMER-A instance-type virtual-routerset routing-instances CUSTOMER-A interface ge-0/0/0.10set routing-instances CUSTOMER-A interface ge-0/0/1.0set routing-instances CUSTOMER-A routing-options router-id 10.1.1.1set routing-instances CUSTOMER-C instance-type virtual-routerset routing-instances CUSTOMER-C interface ge-0/0/0.192set routing-instances CUSTOMER-C interface ge-0/0/2.0set routing-instances CUSTOMER-C routing-options router-id 192.168.1.1[edit]rokk@R1# show | compare [edit]+ routing-instances {+ CUSTOMER-A {+ instance-type virtual-router;+ interface ge-0/0/0.10;+ interface ge-0/0/1.0;+ routing-options {+ router-id 10.1.1.1;+ }+ }+ CUSTOMER-C {+ instance-type virtual-router;+ interface ge-0/0/0.192;+ interface ge-0/0/2.0;+ routing-options {+ router-id 192.168.1.1;+ }+ }+ }I also configured the router id because I will configure OSPF later. Now let's see how the routing table looks after I commit the configuration:
rokk@R1# commit and-quit commit completeExiting configuration moderokk@R1> show route | no-more inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both172.16.1.1/32 *[Direct/0] 00:12:48 > via lo0.0172.16.12.0/30 *[Direct/0] 00:12:48 > via ge-0/0/0.172172.16.12.1/32 *[Local/0] 00:12:48 Local via ge-0/0/0.172CUSTOMER-A.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.0.12.0/30 *[Direct/0] 00:00:05 > via ge-0/0/0.1010.0.12.1/32 *[Local/0] 00:00:05 Local via ge-0/0/0.1010.0.14.0/30 *[Direct/0] 00:00:05 > via ge-0/0/1.010.0.14.1/32 *[Local/0] 00:00:05 Local via ge-0/0/1.0CUSTOMER-C.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both192.168.12.0/30 *[Direct/0] 00:00:05 > via ge-0/0/0.192192.168.12.1/32 *[Local/0] 00:00:05 Local via ge-0/0/0.192192.168.17.0/30 *[Direct/0] 00:00:05 > via ge-0/0/2.0192.168.17.1/32 *[Local/0] 00:00:05 Local via ge-0/0/2.0Now the routing table looks different. We have three of them:
Now we have an instance for every customer, which are completely isolated from one another. Lets ping R1 to R4, from R1 to R7 and then let's try to ping from a customer to another (please look at the topology to understand better):
rokk@R1> ping rapid 10.0.14.2 routing-instance CUSTOMER-A PING 10.0.14.2 (10.0.14.2): 56 data bytes!!!!!--- 10.0.14.2 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.820/1.693/3.566/1.003 msrokk@R1> ping rapid 192.168.17.2 routing-instance CUSTOMER-C PING 192.168.17.2 (192.168.17.2): 56 data bytes!!!!!--- 192.168.17.2 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.409/2.527/6.349/1.917 msrokk@R1> ping rapid 10.0.14.2 routing-instance CUSTOMER-C PING 10.0.14.2 (10.0.14.2): 56 data bytesping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.--- 10.0.14.2 ping statistics ---5 packets transmitted, 0 packets received, 100% packet lossrokk@R1> ping rapid 192.168.17.2 routing-instance CUSTOMER-A PING 192.168.17.2 (192.168.17.2): 56 data bytesping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.ping: sendto: No route to host.--- 192.168.17.2 ping statistics ---5 packets transmitted, 0 packets received, 100% packet lossIf you see that the communication in the same routing instance works, but not between routing instances.
Now if I want to configured OSPF between R1 and R4 I have to configure it under the edit routing-instances CUSTOMER-A stanza and the OSPF configuration between R1 and R7 has to be done under edit routing-instances CUSTOMER-C stanza (or hierarchy). Now the configuration:
rokk@R1# show | compare | no-more [edit]+ routing-options {+ router-id 1.1.1.1;+ }+ protocols {+ ospf {+ area 0.0.0.0 {+ interface lo0.0;+ interface ge-0/0/0.172;+ }+ }+ }[edit routing-instances CUSTOMER-A]+ protocols {+ ospf {+ area 0.0.0.0 {+ interface ge-0/0/1.0;+ interface ge-0/0/0.10;+ }+ }+ }[edit routing-instances CUSTOMER-C]+ protocols {+ ospf {+ area 0.0.0.0 {+ interface ge-0/0/2.0;+ interface ge-0/0/0.192;+ }+ }+ }Now, after I commit the changes I will have a separate neighbor relationship for every routing instance:
rokk@R1# commit and-quit commit completeExiting configuration moderokk@R1> show ospf neighbor Address Interface State ID Pri Dead172.16.12.2 ge-0/0/0.172 Full 2.2.2.2 128 36rokk@R1> show ospf neighbor instance CUSTOMER-A Address Interface State ID Pri Dead10.0.12.2 ge-0/0/0.10 Full 10.2.2.2 128 3610.0.14.2 ge-0/0/1.0 Full 4.4.4.4 1 39rokk@R1> show ospf neighbor instance CUSTOMER-C Address Interface State ID Pri Dead192.168.12.2 ge-0/0/0.192 Full 192.168.2.2 128 35192.168.17.2 ge-0/0/2.0 Full 7.7.7.7 1 31I will post at the end the configuration for every router, but now let's get to the rib-group configuration, because this is the main topic.
Configuring RIB groups involves two steps:
Source: Day One Poster rib-group
Now, after I will create the rib-group configuration, there are several option where I want to apply it:
set routing-options interface-routes rib-group <name>set routing-options rib-group <name>set protocols ospf rib-group <name>The objectives are:
1) ping from R7 the IP address 10.0.14.2 which is configured on R4 e0/0
2) ping from R1 loopback addredd 172.16.1.1 the loopback address, 10.4.4.4, configured on R4, which is which is configured as static route on R1 for Customer A.
3) ping from R4 the loopback address of R7 which is learned trough OSPF.
The configuration for objective one:
The rib-group configuration is always done on the edit routing-options hierarchy, and it's applied to the instance where the routes will be imported:
rokk@R1# show | compare [edit routing-options]+ rib-groups {+ FROM_CUST-A_to_CUST-C {+ import-rib [ CUSTOMER-A.inet.0 CUSTOMER-C.inet.0 ];+ }+ }[edit routing-instances CUSTOMER-A routing-options]+ interface-routes {+ rib-group inet FROM_CUST-A_to_CUST-C;+ }So, here, we created a rib-group wit the name FROM_CUST-A_to_CUST-C and and specified that the routing that is/will be installed into the routing table of Customer A should also now be installed in the routing table of Customer C. And the configured rib-group is applied in the instance from where it will be taken the routing information. So, take what is in the routing table of Customer A and put it in the routing table of Customer C, but when the rib-group is applied on the interface-routes then it actually means: take from Customer A, BUT only the interfaces routes (local and direct) and put them in the routing table of Customer C:
rokk@R1# show | compare [edit routing-options]+ rib-groups {+ FROM_CUST-A_to_CUST-C {+ import-rib [ CUSTOMER-A.inet.0 CUSTOMER-C.inet.0 ];+ }+ }[edit routing-instances CUSTOMER-A routing-options]+ interface-routes {+ rib-group inet FROM_CUST-A_to_CUST-C;+ }The routing table for Customer A before the rib-group configuration:
rokk@R1# run show route table CUSTOMER-A.inet.0 terse CUSTOMER-A.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = BothA V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 10.0.12.0/30 D 0 >ge-0/0/0.10 * ? 10.0.12.1/32 L 0 Local* ? 10.0.14.0/30 D 0 >ge-0/0/1.0 * ? 10.0.14.1/32 L 0 Local* ? 10.0.23.0/30 O 10 2 >10.0.12.2* ? 10.0.25.0/30 O 10 2 >10.0.12.2* ? 10.5.5.5/32 O 10 3 >10.0.12.2* ? 224.0.0.5/32 O 10 1 MultiRecvThe routing table for Customer B before the rib-group configuration:
rokk@R1# run show route table CUSTOMER-C.inet.0 terse CUSTOMER-C.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = BothA V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 192.168.7.7/32 O 10 2 >192.168.17.2* ? 192.168.8.8/32 O 10 3 >192.168.12.2* ? 192.168.12.0/30 D 0 >ge-0/0/0.192* ? 192.168.12.1/32 L 0 Local* ? 192.168.17.0/30 D 0 >ge-0/0/2.0 * ? 192.168.17.1/32 L 0 Local* ? 192.168.23.0/30 O 10 2 >192.168.12.2* ? 192.168.28.0/30 O 10 2 >192.168.12.2* ? 224.0.0.5/32 O 10 1 MultiRecvNow after the configuration is applied we should see the local and direct routes from Customer A routing table to Customer B routing table. Let's see:
rokk@R1# commit and-quit commit completeExiting configuration moderokk@R1> show route table CUSTOMER-C.inet.0 terse CUSTOMER-C.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = BothA V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 10.0.12.0/30 D 0 >ge-0/0/0.10 * ? 10.0.12.1/32 L 0 Local* ? 10.0.14.0/30 D 0 >ge-0/0/1.0 * ? 10.0.14.1/32 L 0 Local* ? 192.168.7.7/32 O 10 2 >192.168.17.2* ? 192.168.8.8/32 O 10 3 >192.168.12.2* ? 192.168.12.0/30 D 0 >ge-0/0/0.192* ? 192.168.12.1/32 L 0 Local* ? 192.168.17.0/30 D 0 >ge-0/0/2.0 * ? 192.168.17.1/32 L 0 Local* ? 192.168.23.0/30 O 10 2 >192.168.12.2* ? 192.168.28.0/30 O 10 2 >192.168.12.2* ? 224.0.0.5/32 O 10 1 MultiRecvThe objective was to ping from R7 the IP address 10.0.14.2 the interface e0/0 on R4. The problem is that the imported routes are only on R1 and not on R7.
R7#show ip route 10.0.14.0% Network not in tableFor the route 10.0.14.0/30 to be in R7 routing table we have to create a policy and export the policy trough OSPF.
Before that we have now in the routing table of Customer C 2 routes from the routing table of Customer A, which are 10.0.14.0/30 and 10.0.12.0/30. Let's permit only the route 10.0.14.0/30 to be advertised from the routing table of Customer A to the routing table of Customer C. For this to happen we also have to create a policy and apply this as an import policy to the rib-group I've created. OK, let's do this:
rokk@R1# show | no-more......policy-options { policy-statement DIRECT-R1-R4 { term 1 { from { protocol direct; route-filter 10.0.14.0/30 exact; } then accept; } term 2 { then reject; } } policy-statement EXPORT_to_OSPF { term 1 { from { protocol direct; route-filter 10.0.14.0/30 exact; } then accept; } term 2 { then reject; } }}.......routing-options { rib-groups { FROM_CUST-A_to_CUST-C { import-rib [ CUSTOMER-A.inet.0 CUSTOMER-C.inet.0 ]; import-policy DIRECT-R1-R4; } } router-id 1.1.1.1;}........routing-instances {... CUSTOMER-C { instance-type virtual-router; interface ge-0/0/0.192; interface ge-0/0/2.0; routing-options { router-id 192.168.1.1; } protocols { ospf { export EXPORT_to_OSPF; area 0.0.0.0 { interface ge-0/0/2.0; interface ge-0/0/0.192; } } } }}.......So the policy DIRECT-R1-R4 was created which says: take from protocol direct the exact route 10.0.14.0/30 and nothing else. And it's applied to the rib-group FROM_CUST-A_to_CUST-C.
Then policy EXPORT_to_OSPF was created which says exactly the same as the above policy, but is applied to the protocol OSPF in the instance of Customer C as an export policy.
Let's see the result on R1, routing table CUSTOMER-C.inet.0 and the routing table on R7:
rokk@R1> show route table CUSTOMER-C.inet.0 terse CUSTOMER-C.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = BothA V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 10.0.14.0/30 D 0 >ge-0/0/1.0 * ? 192.168.7.7/32 O 10 2 >192.168.17.2* ? 192.168.8.8/32 O 10 3 >192.168.12.2* ? 192.168.12.0/30 D 0 >ge-0/0/0.192* ? 192.168.12.1/32 L 0 Local* ? 192.168.17.0/30 D 0 >ge-0/0/2.0 * ? 192.168.17.1/32 L 0 Local* ? 192.168.23.0/30 O 10 2 >192.168.12.2* ? 192.168.28.0/30 O 10 2 >192.168.12.2* ? 224.0.0.5/32 O 10 1 MultiRecvSo now we have only one of the routes imported, 10.0.14.0/30. This is the result of the policy applied to the rig-group.
R7#show ip route 10.0.14.0Routing entry for 10.0.14.0/30 Known via "ospf 1", distance 110, metric 0, type extern 2, forward metric 10 Last update from 192.168.17.1 on Ethernet0/0, 00:03:03 ago Routing Descriptor Blocks: * 192.168.17.1, from 192.168.1.1, 00:03:03 ago, via Ethernet0/0 Route metric is 0, traffic share count is 1Now let's ping from R7 to the e0/0 on R4:
R7#ping 10.0.14.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.0.14.2, timeout is 2 seconds:.....Success rate is 0 percent (0/5)Well, it's not working. Maybe something was wrong configured you think. It's not that. The problem is that not everything was configured. We have created here one way routing, which means R7 knows how to get to R4, but does R4 know how to return the traffic to R7? Let's see:
R4#show ip route 192.168.17.0% Network not in tableSo no. Then what needs to be done. Well we have to create the same thing but in the opposite direction. The steps are:
And this is the configuration (I will paste the configuration as display set here to save some space):
set policy-options policy-statement DIRECT-R1-R7 term 1 from protocol directset policy-options policy-statement DIRECT-R1-R7 term 1 from route-filter 192.168.17.0/30 exactset policy-options policy-statement DIRECT-R1-R7 term 1 then acceptset policy-options policy-statement DIRECT-R1-R7 term 2 then rejectset policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol directset policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exactset policy-options policy-statement EXPORT_to_OSPF-A term 1 then acceptset policy-options policy-statement EXPORT_to_OSPF-A term 2 then rejectset routing-options rib-groups FROM_CUST-C_to_CUST-A import-rib CUSTOMER-C.inet.0set routing-options rib-groups FROM_CUST-C_to_CUST-A import-rib CUSTOMER-A.inet.0set routing-options rib-groups FROM_CUST-C_to_CUST-A import-policy DIRECT-R1-R7set routing-instances CUSTOMER-C routing-options interface-routes rib-group inet FROM_CUST-C_to_CUST-Aset routing-instances CUSTOMER-A protocols ospf export EXPORT_to_OSPF-ANow in the routing table of Customer A we should see only the directly connected route 192.167.17.0/30
rokk@R1> show route terse table CUSTOMER-A.inet.0 CUSTOMER-A.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = BothA V Destination P Prf Metric 1 Metric 2 Next hop AS path* ? 10.0.12.0/30 D 0 >ge-0/0/0.10 * ? 10.0.12.1/32 L 0 Local* ? 10.0.14.0/30 D 0 >ge-0/0/1.0 * ? 10.0.14.1/32 L 0 Local* ? 10.0.23.0/30 O 10 2 >10.0.12.2* ? 10.0.25.0/30 O 10 2 >10.0.12.2* ? 10.5.5.5/32 O 10 3 >10.0.12.2* ? 192.168.17.0/30 D 0 >ge-0/0/2.0 * ? 224.0.0.5/32 O 10 1 MultiRecvLet's see also if we have now a route on R4 for the subnet 172.168.17.0/30
R4#show ip route 192.168.17.1 Routing entry for 192.168.17.0/30 Known via "ospf 1", distance 110, metric 0, type extern 2, forward metric 10 Last update from 10.0.14.1 on Ethernet0/0, 00:06:03 ago Routing Descriptor Blocks: * 10.0.14.1, from 10.1.1.1, 00:06:03 ago, via Ethernet0/0 Route metric is 0, traffic share count is 1Looks good. Let's try again to ping from R7 to R4 interface e0/0
R7#ping 10.0.14.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.0.14.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/4 msOK. Now let's see objective 2: "ping from R1 loopback addredd 172.16.1.1 the loopback address, 10.4.4.4, configured on R4, which is which is configured as static route on R1 for Customer A"
For this we have to create a static route on R1 to know how to get to R4, the loopback interface 10.4.4.4, then configure a rib-group to share the static route from Customer A to the default routing instance. And for the return traffic, we will create a static route in Customer A instance that is pointing to the master/default routing instance and export that trough OSPF to R4. Let's take a look at the routing table for the two loopback addresses:
rokk@R1> show route table CUSTOMER-A.inet.0 172.16.1.1 rokk@R1> R4#show ip route 172.16.1.1% Network not in tableSo Customer A has no idea how to get to 172.16.1.1
rokk@R1> show route table inet.0 10.4.4.4 rokk@R1> And the master/default routing instance has no route to 10.4.4.4.
Now let's fix that:
set routing-options rib-groups CUST-A_to_MASTER import-rib CUSTOMER-A.inet.0set routing-options rib-groups CUST-A_to_MASTER import-rib inet.0set routing-instances CUSTOMER-A routing-options static rib-group CUST-A_to_MASTERset routing-instances CUSTOMER-A routing-options static route 10.4.4.4/32 next-hop 10.0.14.2set routing-instances CUSTOMER-A routing-options static route 172.16.1.1/32 next-table inet.0set policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol directset policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exactset policy-options policy-statement EXPORT_to_OSPF-A term 1 then acceptset policy-options policy-statement EXPORT_to_OSPF-A term 2 from protocol staticset policy-options policy-statement EXPORT_to_OSPF-A term 2 from route-filter 172.16.1.1/32 exactset policy-options policy-statement EXPORT_to_OSPF-A term 2 then acceptset policy-options policy-statement EXPORT_to_OSPF-A term 3 then rejectNow let's look at the routing table again:
rokk@R1> show route table CUSTOMER-A.inet.0 172.16.1.1 CUSTOMER-A.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both172.16.1.1/32 *[Static/5] 00:05:18 to table inet.0-------------------------------------------------------------------------------------R4#show ip route 172.16.1.1Routing entry for 172.16.1.1/32 Known via "ospf 1", distance 110, metric 0, type extern 2, forward metric 10 Last update from 10.0.14.1 on Ethernet0/0, 00:00:04 ago Routing Descriptor Blocks: * 10.0.14.1, from 10.1.1.1, 00:00:04 ago, via Ethernet0/0 Route metric is 0, traffic share count is 1--------------------------------------------------------------------------------------rokk@R1> show route table inet.0 10.4.4.4 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.4.4.4/32 *[Static/5] 00:05:49 > to 10.0.14.2 via ge-0/0/1.0You also that the export policy EXPORT_to_OSPF-A was modified to include the static route for 172.16.1.1/32 and export this trough OSPF to R4. Now let's try a ping from loopback address of R1 to the loopback address of R4:
rokk@R1> ping rapid 10.4.4.4 source 172.16.1.1 PING 10.4.4.4 (10.4.4.4): 56 data bytes!!!!!--- 10.4.4.4 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 1.564/2.169/3.619/0.742 msNow the last objective was "ping from R4 the loopback address of R7 which is learned trough OSPF".
But, let's modify this with: ping from loopback address of R4 to the loopback address of R7 which is learned trough OSPF.
Let's see at the routing table of R4 and R7:
R4#show ip route 192.168.7.7% Network not in table-----------------------------------------R7#show ip route 10.4.4.4% Subnet not in tableSo R7 has no route to the loopback address on R4 and R4 has no route to the loopback address on R7.
We will create two rig groups to share the routing tables between the two routing instances, but with a policy to advertise only a specific route.
And the configuration:
set policy-options policy-statement R7-loopback term 1 from protocol ospfset policy-options policy-statement R7-loopback term 1 from route-filter 192.168.7.7/32 exactset policy-options policy-statement R7-loopback term 1 then acceptset policy-options policy-statement R7-loopback term 2 then rejectset routing-options rib-groups CUST-C_to_CUST-A import-rib CUSTOMER-C.inet.0set routing-options rib-groups CUST-C_to_CUST-A import-rib CUSTOMER-A.inet.0set routing-options rib-groups CUST-C_to_CUST-A import-policy R7-loopbackset routing-instances CUSTOMER-C protocols ospf rib-group CUST-C_to_CUST-Aset routing-instances CUSTOMER-C routing-options static route 10.4.4.4/32 next-table CUSTOMER-A.inet.0set policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol directset policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exactset policy-options policy-statement EXPORT_to_OSPF-A term 1 then acceptset policy-options policy-statement EXPORT_to_OSPF-A term 2 from protocol staticset policy-options policy-statement EXPORT_to_OSPF-A term 2 from route-filter 172.16.1.1/32 exactset policy-options policy-statement EXPORT_to_OSPF-A term 2 then acceptset policy-options policy-statement EXPORT_to_OSPF-A term 3 from protocol ospfset policy-options policy-statement EXPORT_to_OSPF-A term 3 from route-filter 192.168.7.7/32 exactset policy-options policy-statement EXPORT_to_OSPF-A term 3 then acceptset policy-options policy-statement EXPORT_to_OSPF-A then rejectset policy-options policy-statement EXPORT_to_OSPF term 1 from protocol directset policy-options policy-statement EXPORT_to_OSPF term 1 from route-filter 10.0.14.0/30 exactset policy-options policy-statement EXPORT_to_OSPF term 1 then acceptset policy-options policy-statement EXPORT_to_OSPF term 2 from protocol staticset policy-options policy-statement EXPORT_to_OSPF term 2 from route-filter 10.4.4.4/32 exactset policy-options policy-statement EXPORT_to_OSPF term 2 then acceptset policy-options policy-statement EXPORT_to_OSPF term 3 then rejectAs you can see I've created a policy named R7-loopback, which was added to the rib-group CUST-C_to_CUST-A which was added to protocol OSPF on routing instance of Customer C. Then I've created a static route for 10.4.4.4/32 wit the next hope of table CUSTOMER-A.inet.0. Then I've modified the two export policies which where already configured for the two instances.
Let's look now at the routing tables of the three routers:
R4#show ip route 192.168.7.7Routing entry for 192.168.7.7/32 Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 10 Last update from 10.0.14.1 on Ethernet0/0, 00:00:04 ago Routing Descriptor Blocks: * 10.0.14.1, from 10.1.1.1, 00:00:04 ago, via Ethernet0/0 Route metric is 2, traffic share count is 1---------------------------------------------------------------------------------------------R7#show ip route 10.4.4.4Routing entry for 10.4.4.4/32 Known via "ospf 1", distance 110, metric 0, type extern 2, forward metric 10 Last update from 192.168.17.1 on Ethernet0/0, 00:00:04 ago Routing Descriptor Blocks: * 192.168.17.1, from 192.168.1.1, 00:00:04 ago, via Ethernet0/0 Route metric is 0, traffic share count is 1----------------------------------------------------------------------------------------------rokk@R1> show route table CUSTOMER-C.inet.0 10.4.4.4 CUSTOMER-C.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.4.4.4/32 *[Static/5] 00:12:00 to table CUSTOMER-A.inet.0----------------------------------------------------------------------------------------------rokk@R1> show route table CUSTOMER-A.inet.0 192.168.7.7 CUSTOMER-A.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both192.168.7.7/32 *[OSPF/10] 00:17:48, metric 2 > to 192.168.17.2 via ge-0/0/2.0Now let's try a ping from R4 to R7 and back from R7 to R4:
R4#ping 192.168.7.7 source 10.4.4.4 Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.7.7, timeout is 2 seconds:Packet sent with a source address of 10.4.4.4 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms------------------------------------------------------------------------R7#ping 10.4.4.4 source 192.168.7.7Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:Packet sent with a source address of 192.168.7.7 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 msI know it's a dam long blog post I will do tomorrow a video an post it on youtube where you will see exactly how I did this.
And the youtube video.
And as promise, the configuration for R1, R4 and R7.
Thank you and see you in the next blog post.