Monday, March 17, 2014

Juniper Route Leaking Part 4 - Static Routes and Filter Based Forwarding

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