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.10
set system host-name R1
set system root-authentication encrypted-password "$1$bMF3smWb$uDXn91gyB6J9cJ2FYu56Q."
set system login user admin uid 2000
set system login user admin class super-user
set system login user admin authentication encrypted-password "$1$OUFAeSiu$/2miGlGHTPzKT8g3ssZVZ/"
set system login user rokk uid 2001
set system login user rokk class super-user
set system login user rokk authentication encrypted-password "$1$Apro5K8R$FHKeID3dcr2l5xvu8fJV71"
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
If 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-tagging
set interfaces ge-0/0/0 unit 10 vlan-id 10
set interfaces ge-0/0/0 unit 10 family inet address 10.0.12.1/30
set interfaces ge-0/0/0 unit 172 vlan-id 172
set interfaces ge-0/0/0 unit 172 family inet address 172.16.12.1/30
set interfaces ge-0/0/0 unit 192 vlan-id 192
set interfaces ge-0/0/0 unit 192 family inet address 192.168.12.1/30
set 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/30
set 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/30
set interfaces lo0 unit 0 family inet address 172.16.1.1/32
This 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 complete
Exiting configuration mode
rokk@R1> show route | no-more
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.12.0/30 *[Direct/0] 00:00:05
> via ge-0/0/0.10
10.0.12.1/32 *[Local/0] 00:00:05
Local via ge-0/0/0.10
10.0.14.0/30 *[Direct/0] 00:00:05
> via ge-0/0/1.0
10.0.14.1/32 *[Local/0] 00:00:05
Local via ge-0/0/1.0
172.16.1.1/32 *[Direct/0] 00:00:05
> via lo0.0
172.16.12.0/30 *[Direct/0] 00:00:05
> via ge-0/0/0.172
172.16.12.1/32 *[Local/0] 00:00:05
Local via ge-0/0/0.172
192.168.12.0/30 *[Direct/0] 00:00:05
> via ge-0/0/0.192
192.168.12.1/32 *[Local/0] 00:00:05
Local via ge-0/0/0.192
192.168.17.0/30 *[Direct/0] 00:00:05
> via ge-0/0/2.0
192.168.17.1/32 *[Local/0] 00:00:05
Local via ge-0/0/2.0
If 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-router
set routing-instances CUSTOMER-A interface ge-0/0/0.10
set routing-instances CUSTOMER-A interface ge-0/0/1.0
set routing-instances CUSTOMER-A routing-options router-id 10.1.1.1
set routing-instances CUSTOMER-C instance-type virtual-router
set routing-instances CUSTOMER-C interface ge-0/0/0.192
set routing-instances CUSTOMER-C interface ge-0/0/2.0
set 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 complete
Exiting configuration mode
rokk@R1> show route | no-more
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[Direct/0] 00:12:48
> via lo0.0
172.16.12.0/30 *[Direct/0] 00:12:48
> via ge-0/0/0.172
172.16.12.1/32 *[Local/0] 00:12:48
Local via ge-0/0/0.172
CUSTOMER-A.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.12.0/30 *[Direct/0] 00:00:05
> via ge-0/0/0.10
10.0.12.1/32 *[Local/0] 00:00:05
Local via ge-0/0/0.10
10.0.14.0/30 *[Direct/0] 00:00:05
> via ge-0/0/1.0
10.0.14.1/32 *[Local/0] 00:00:05
Local via ge-0/0/1.0
CUSTOMER-C.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.12.0/30 *[Direct/0] 00:00:05
> via ge-0/0/0.192
192.168.12.1/32 *[Local/0] 00:00:05
Local via ge-0/0/0.192
192.168.17.0/30 *[Direct/0] 00:00:05
> via ge-0/0/2.0
192.168.17.1/32 *[Local/0] 00:00:05
Local via ge-0/0/2.0
Now 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 loss
round-trip min/avg/max/stddev = 0.820/1.693/3.566/1.003 ms
rokk@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 loss
round-trip min/avg/max/stddev = 1.409/2.527/6.349/1.917 ms
rokk@R1> ping rapid 10.0.14.2 routing-instance CUSTOMER-C
PING 10.0.14.2 (10.0.14.2): 56 data bytes
ping: 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 loss
rokk@R1> ping rapid 192.168.17.2 routing-instance CUSTOMER-A
PING 192.168.17.2 (192.168.17.2): 56 data bytes
ping: 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 loss
If 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 complete
Exiting configuration mode
rokk@R1> show ospf neighbor
Address Interface State ID Pri Dead
172.16.12.2 ge-0/0/0.172 Full 2.2.2.2 128 36
rokk@R1> show ospf neighbor instance CUSTOMER-A
Address Interface State ID Pri Dead
10.0.12.2 ge-0/0/0.10 Full 10.2.2.2 128 36
10.0.14.2 ge-0/0/1.0 Full 4.4.4.4 1 39
rokk@R1> show ospf neighbor instance CUSTOMER-C
Address Interface State ID Pri Dead
192.168.12.2 ge-0/0/0.192 Full 192.168.2.2 128 35
192.168.17.2 ge-0/0/2.0 Full 7.7.7.7 1 31
I 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, * = Both
A 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 MultiRecv
The 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, * = Both
A 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 MultiRecv
Now 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 complete
Exiting configuration mode
rokk@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, * = Both
A 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 MultiRecv
The 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 table
For 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, * = Both
A 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 MultiRecv
So 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.0
Routing 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 1
Now let's ping from R7 to the e0/0 on R4:
R7#ping 10.0.14.2
Type 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 table
So 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 direct
set policy-options policy-statement DIRECT-R1-R7 term 1 from route-filter 192.168.17.0/30 exact
set policy-options policy-statement DIRECT-R1-R7 term 1 then accept
set policy-options policy-statement DIRECT-R1-R7 term 2 then reject
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol direct
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 1 then accept
set policy-options policy-statement EXPORT_to_OSPF-A term 2 then reject
set routing-options rib-groups FROM_CUST-C_to_CUST-A import-rib CUSTOMER-C.inet.0
set routing-options rib-groups FROM_CUST-C_to_CUST-A import-rib CUSTOMER-A.inet.0
set routing-options rib-groups FROM_CUST-C_to_CUST-A import-policy DIRECT-R1-R7
set routing-instances CUSTOMER-C routing-options interface-routes rib-group inet FROM_CUST-C_to_CUST-A
set routing-instances CUSTOMER-A protocols ospf export EXPORT_to_OSPF-A
Now 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, * = Both
A 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 MultiRecv
Let'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 1
Looks good. Let's try again to ping from R7 to R4 interface e0/0
R7#ping 10.0.14.2
Type 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 ms
OK. 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 table
So 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.0
set routing-options rib-groups CUST-A_to_MASTER import-rib inet.0
set routing-instances CUSTOMER-A routing-options static rib-group CUST-A_to_MASTER
set routing-instances CUSTOMER-A routing-options static route 10.4.4.4/32 next-hop 10.0.14.2
set routing-instances CUSTOMER-A routing-options static route 172.16.1.1/32 next-table inet.0
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol direct
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 1 then accept
set policy-options policy-statement EXPORT_to_OSPF-A term 2 from protocol static
set policy-options policy-statement EXPORT_to_OSPF-A term 2 from route-filter 172.16.1.1/32 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 2 then accept
set policy-options policy-statement EXPORT_to_OSPF-A term 3 then reject
Now 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, * = Both
172.16.1.1/32 *[Static/5] 00:05:18
to table inet.0
-------------------------------------------------------------------------------------
R4#show ip route 172.16.1.1
Routing 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, * = Both
10.4.4.4/32 *[Static/5] 00:05:49
> to 10.0.14.2 via ge-0/0/1.0
You 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 loss
round-trip min/avg/max/stddev = 1.564/2.169/3.619/0.742 ms
Now 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 table
So 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 ospf
set policy-options policy-statement R7-loopback term 1 from route-filter 192.168.7.7/32 exact
set policy-options policy-statement R7-loopback term 1 then accept
set policy-options policy-statement R7-loopback term 2 then reject
set routing-options rib-groups CUST-C_to_CUST-A import-rib CUSTOMER-C.inet.0
set routing-options rib-groups CUST-C_to_CUST-A import-rib CUSTOMER-A.inet.0
set routing-options rib-groups CUST-C_to_CUST-A import-policy R7-loopback
set routing-instances CUSTOMER-C protocols ospf rib-group CUST-C_to_CUST-A
set routing-instances CUSTOMER-C routing-options static route 10.4.4.4/32 next-table CUSTOMER-A.inet.0
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from protocol direct
set policy-options policy-statement EXPORT_to_OSPF-A term 1 from route-filter 192.168.17.0/30 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 1 then accept
set policy-options policy-statement EXPORT_to_OSPF-A term 2 from protocol static
set policy-options policy-statement EXPORT_to_OSPF-A term 2 from route-filter 172.16.1.1/32 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 2 then accept
set policy-options policy-statement EXPORT_to_OSPF-A term 3 from protocol ospf
set policy-options policy-statement EXPORT_to_OSPF-A term 3 from route-filter 192.168.7.7/32 exact
set policy-options policy-statement EXPORT_to_OSPF-A term 3 then accept
set policy-options policy-statement EXPORT_to_OSPF-A then reject
set policy-options policy-statement EXPORT_to_OSPF term 1 from protocol direct
set policy-options policy-statement EXPORT_to_OSPF term 1 from route-filter 10.0.14.0/30 exact
set policy-options policy-statement EXPORT_to_OSPF term 1 then accept
set policy-options policy-statement EXPORT_to_OSPF term 2 from protocol static
set policy-options policy-statement EXPORT_to_OSPF term 2 from route-filter 10.4.4.4/32 exact
set policy-options policy-statement EXPORT_to_OSPF term 2 then accept
set policy-options policy-statement EXPORT_to_OSPF term 3 then reject
As 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.7
Routing 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.4
Routing 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, * = Both
10.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, * = Both
192.168.7.7/32 *[OSPF/10] 00:17:48, metric 2
> to 192.168.17.2 via ge-0/0/2.0
Now 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.7
Type 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 ms
I 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.