In previous post, we discussed how to route leak routes in
JUNOS using RIB Groups, Instance Import and VRF Route Targets and Auto-Export. In
this final post we’re going to discuss how we do this using firewall filters
and static routes, both of them are really easy to configure but with a few
caveats.
Static Routes
Let’s configure a static route in the routing table R2.inet.0
that points to R1 loopback 1.1.1.1 in the routing table inet.0
root@R3>
show configuration routing-instances R2 routing-options
static
{
route 1.1.1.1/32 next-table inet.0;
}
After we
commit
root@R3>
show route table R2.inet.0
R2.inet.0:
5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+
= Active Route, - = Last Active, * = Both
1.1.1.1/32
*[Static/5] 00:00:53
to table inet.0
2.2.2.2/32 *[OSPF/10] 00:45:23, metric 1
> to 10.0.23.2 via
ge-0/0/2.0
10.0.23.0/24 *[Direct/0] 00:45:32
> via ge-0/0/2.0
10.0.23.3/32 *[Local/0] 00:45:32
Local via ge-0/0/2.0
224.0.0.5/32 *[OSPF/10] 00:45:33, metric 1
MultiRecv
Checking
R2.inet.0 routing table on router R3, the static route to 1.1.1.1/32 is clearly
there with inet.0 as a next-hop. Let’s export (redistribute) to R3.inet.0 OSPF
protocol so that R2 can reach the prefix 1.1.1.1/32
root@R3#
show policy-options policy-statement EXPORT-TO-R2-OSPF
term
1 {
from protocol static;
}
then
accept;
root@R3#
show routing-instances R2 protocols ospf
export
EXPORT-TO-R2-OSPF;
area
0.0.0.1 {
interface ge-0/0/2.0;
}
And the
route 1.1.1.1/32 arrived safely to the router R2 as an OSPF external route
root@R2>
show route
inet.0:
7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+
= Active Route, - = Last Active, * = Both
2.2.2.2/32 *[Direct/0] 01:43:20
> via lo0.10
1.1.1.1/32
*[OSPF/150] 00:00:04, metric 0, tag 0
> to 10.0.23.3 via ge-0/0/2.0
10.0.23.0/24 *[Direct/0] 01:43:15
> via ge-0/0/2.0
10.0.23.2/32 *[Local/0] 01:43:16
Local via ge-0/0/2.0
10.94.160.0/20 *[Direct/0] 01:43:08
> via ge-0/0/0.0
10.94.169.241/32 *[Local/0] 01:43:08
Local via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 01:43:26, metric 1
MultiRecv
Now,
here’s the catch, we’ve managed to get the R2 to reach the prefix 1.1.1.1/32,
but what about the other way around? Let’s try to configure a route from inet.0
to R2.inet.0 on R3 to allow 2 way communication
[edit]
root@R3#
set routing-options static route 2.2.2.2/32 next-table R2.inet.0
[edit]
root@R3#
commit
error: [rib inet.0 routing-options static]
next-table may loop
error:
configuration check-out failed
The
commit Failed, the reason is JUNOS prevents you from configuring bi-directional
static routes between 2 routing-instances to eliminate the possibility of a
routing loop happening.
In this
case, we’ll have to use of the previously mentioned route leaking methods in
conjunction with static route leaking to accomplish bi-directional communication
between routing instances OR we can also use the Filter Based Forwarding which
will be the final method to close this series.
Filter-Based Forwarding
Filter
based forwarding is very similar in implementation to Policy-Based Routing(PBR). In our case here, we’ll use FBF to direct incoming packets from R1 to
R2.inet.0 routing table
There
are two components of FBF
1.
A firewall filter that has certain match criteria ( SRC/DST IP,
Port numbers, COS etc..) which then points to a specific routing table
2.
Apply that firewall filter under the incoming interface
Let’s
see how we can do this
First,
let’s create a firewall filter that matches source IP 1.1.1.1/32 and redirect
it to R2.inet.0, and then we apply that under the incoming interface ge-0/0/1
root@R3>
show configuration firewall
family
inet {
filter FROM-R1-TO-R2-ROUTING-TABLE {
term 1 {
from {
source-address {
1.1.1.1/32;
}
}
then {
routing-instance R2;
}
}
term 2 {
then accept;
}
}
}
root@R3>
show configuration interfaces ge-0/0/1
unit
0 {
family inet {
filter {
input FROM-R1-TO-R2-ROUTING-TABLE;
}
address 10.0.13.3/24;
}
family mpls;
}
Up till
now, R1 doesn’t know how to get to 2.2.2.2/32, we can simply configure a static
route on R1 pointing to R3 in order to reach 2.2.2.2/32 subnet
root@R1>
show configuration routing-options
static
{
route
2.2.2.2/32 next-hop 10.0.13.3;
Let’s
try to ping and traceroute from R2 to R1
root@R2>
ping 1.1.1.1 source 2.2.2.2
PING
1.1.1.1 (1.1.1.1): 56 data bytes
64
bytes from 1.1.1.1: icmp_seq=0 ttl=63 time=4.890 ms
64
bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=8.144 ms
64
bytes from 1.1.1.1: icmp_seq=2 ttl=63 time=8.310 ms
^C
---
1.1.1.1 ping statistics ---
3
packets transmitted, 3 packets received, 0% packet loss
round-trip
min/avg/max/stddev = 4.890/7.115/8.310/1.575 ms
root@R2>
traceroute 1.1.1.1 source 2.2.2.2
traceroute
to 1.1.1.1 (1.1.1.1) from 2.2.2.2, 30 hops max, 40 byte packets
1
10.0.23.3 (10.0.23.3) 6.467
ms 5.239 ms 6.052 ms
2
1.1.1.1 (1.1.1.1) 7.612 ms 6.583 ms
9.763 ms
Looks pretty
good!
Before
closing this, there’s a little limitation regarding the FBF method. i’ll put it
into bullets
·
You can redirect packets from inet.0 to any user configured instance
·
You can redirect packets from any user configured instance to another
·
You CAN’T redirect packets from any user configured instance to
inet.0
Hopefully
this Series managed to make the powerful route leaking techniques in Juniper
JUNOS easy to understand and to implement
Thank so much.
ReplyDeleteVery helpful article.