JNCIP-SEC [ 2 – Virtualization ]
According to exam topics I will focus on routing instances, routing between instances and filter based forwarding. Lets get started;
Routing Instances
Routing instances may be considered to be virtual routers within a physical router configured like below. I have two virtual routers configured each of which inherits one interface from physical router. In configuring these instances, be careful that these interfaces must belong to different zones since two interfaces cannot be in the same zone while they are in different routing instances.
[edit]
root@host# show routing-instances
RA {
instance-type virtual-router;
interface vlan.100;
}
RB {
instance-type virtual-router;
interface vlan.200;
}
To display routing tables on both routing instances;
[edit]
root@host# run show route table RA.inet.0
RA.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.1.100.0/24 *[Direct/0] 00:02:20
> via vlan.100
10.1.100.2/32 *[Local/0] 00:02:20
Local via vlan.100
[edit]
root@host# run show route table RB.inet.0
RB.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.1.200.0/24 *[Direct/0] 01:26:36
> via vlan.200
10.1.200.2/32 *[Local/0] 01:27:20
Local via vlan.200
[edit]
root@host# run show route table inet.0
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
0.0.0.0/0 *[Static/5] 01:34:52
> to 172.30.72.1 via ge-0/0/0.0
10.1.10.0/24 *[Direct/0] 01:13:41
> via vlan.10
10.1.10.1/32 *[Local/0] 01:13:41
Local via vlan.10
10.1.20.0/24 *[Direct/0] 01:13:41
> via vlan.20
10.1.20.1/32 *[Local/0] 01:13:41
Local via vlan.20
172.30.72.0/23 *[Direct/0] 01:34:52
> via ge-0/0/0.0
172.30.72.244/32 *[Local/0] 01:34:52
Local via ge-0/0/0.0
192.168.1.0/24 *[Direct/0] 00:26:17
> via ge-0/0/1.0
192.168.1.1/32 *[Local/0] 00:26:17
Local via ge-0/0/1.0
192.168.3.0/24 *[Direct/0] 00:04:43
> via ge-0/0/3.0
192.168.3.1/32 *[Local/0] 00:04:43
Local via ge-0/0/3.0
As we can virtually say these two new routers are separate, they are all unaware of each other from routing table point of view. Neither physical router or routing instances can reach each other. How can we share routes between them? One option is to use rib-groups:
[edit routing-options]
root@host# show
interface-routes {
rib-group inet masterToInstances;
}
rib-groups {
masterToInstances {
import-rib [ inet.0 RA.inet.0 RB.inet.0 ];
}
}
The above configuration literally says take routes in inet.0 table and copy them onto RA and RB routing instances which indeed has the following output. As you can see below all routes in inet.0 now are available in routing instances too. The point to mention is rib-groups configuration isn’t enough itself. You must apply it under interface-routes section in order to copy routing tables. After commit you can see that inet.0 routes appear under RA.inet.0 too.
[edit routing-options]
root@host# run show route table RA.inet.0
RA.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.1.10.0/24 *[Direct/0] 00:00:13
> via vlan.10
10.1.10.1/32 *[Local/0] 00:00:13
Local via vlan.10
10.1.20.0/24 *[Direct/0] 00:00:13
> via vlan.20
10.1.20.1/32 *[Local/0] 00:00:13
Local via vlan.20
10.1.100.0/24 *[Direct/0] 00:10:13
> via vlan.100
10.1.100.2/32 *[Local/0] 00:10:13
Local via vlan.100
172.30.72.0/23 *[Direct/0] 00:00:13
> via ge-0/0/0.0
172.30.72.244/32 *[Local/0] 00:00:13
Local via ge-0/0/0.0
192.168.1.0/24 *[Direct/0] 00:00:13
> via ge-0/0/1.0
192.168.1.1/32 *[Local/0] 00:00:13
Local via ge-0/0/1.0
192.168.3.0/24 *[Direct/0] 00:00:13
> via ge-0/0/3.0
192.168.3.1/32 *[Local/0] 00:00:13
Local via ge-0/0/3.0
Let’s make a ping test:
root@host# run ping 192.168.1.1 routing-instance RA
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=65 time=1.841 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=65 time=1.299 ms
^C
Checking Point:
If your ping doesn’t work make sure;
a) All interfaces are in the correct zones
b) Security policy from RA to physical router allows icmp traffic
c) Remote interface has host-inbound-traffic set correctly for system-services
There is one more point. The above configuration will not import static routes but only interface routes. If you want to import static routes from inet.0 to RA and RB routing instances, here is the configuration;
[edit routing-options]
root@host# show
interface-routes {
rib-group inet masterToInstances;
}
static {
rib-group static-To-Instances;
route 0.0.0.0/0 next-hop 172.30.72.1;
route 144.122.0.0/16 next-hop 172.30.72.103;
}
rib-groups {
masterToInstances {
import-rib [ inet.0 RA.inet.0 RB.inet.0 ];
}
static-To-Instances {
import-rib [ inet.0 RA.inet.0 RB.inet.0 ];
}
}
Filter Based Forwarding
Another topic is filter based forwarding or policy based forwarding. I will use my simple topology below. Because I have only one device, I have to use vlan interfaces and some assumptions in my setup but it should resemble a real setup as much as possible. Here it is;
I will forward requests coming from PC1 to ISP1 and PC2 to ISP2 (Start with a clean config)
1) Create filters which will direct traffic to respective routing instances
[edit firewall]
root@host# show
filter vlan100-filter {
term fbf {
from {
source-address {
10.1.100.0/24;
}
}
then {
routing-instance RA;
}
}
}
filter vlan200-filter {
term fbf {
from {
source-address {
10.1.200.0/24;
}
}
then {
routing-instance RB;
}
}
}
2) Create routing instances
[edit routing-instances]
root@host# show
RA {
instance-type forwarding;
interface vlan.100;
routing-options {
static {
route 0.0.0.0/0 next-hop 144.122.211.1;
}
}
}
RB {
instance-type forwarding;
interface vlan.200;
routing-options {
static {
route 0.0.0.0/0 next-hop 212.45.64.1;
}
}
}
3) Create rib groups
[edit routing-options]
root@host# show
interface-routes {
rib-group inet master-To-instances;
}
static {
route 0.0.0.0/0 next-hop 172.30.72.1;
}
rib-groups {
master-To-instances {
import-rib [ inet.0 RA.inet.0 RB.inet.0 ];
}
}
After all these configurations and policies, traffic should be forwarded selectively. I haven’t really tested this setup but I have tested in different scenarios. This setup I have done above is just to explain the functionality.
Nice post for rib-group. I got it now. Thanks.
Hi, first of all thanks a lot for explaining this issue with an example. On the other hand i would not suggest users to use this option with low end branch office series devices which may effect performance. Even if you have an srx240 with 1000 lines of config you will face performance downgrades. For options like pbr fbf its best to try them with chassis like 1400 and above which have higher capacities. Thanks again for sharing this information.
Thanks for feedback. Actually I haven’t tried this on a busy production environment but I would love to hear your feedback if you have a performance issue on a 240 series device related to FBF. To me this shouldn’t have much performance implication. Firewall filter is before flow processing and uses much less resources but your feedback is welcomed.
Cheers.