Cisco Route Map Equivalent in Juniper JUNOS – How to Configure

ciscojuniper

Here is a scenario and working route-map example for Policy base routing.
I'm new Junos i'm struggling with Firewall filters and Policy-statements in Junos.

Can you help me to convert this simple scenario from Cisco IOS to JUNOS equivalent.

What it does below it matchs a packet from any source but destination 200.100.30.248/29 and set its next hop to 192.168.1.1

Matching criteria using Access List

access-list 104 permit ip any 202.100.30.248 0.0.0.7 log-input

Route-map

route-map PBR permit 10
 match ip address 104
 set ip default next-hop 192.168.1.1

And at the End it is applied.

interface FastEthernet0/1  
 ip address 172.16.1.2 255.255.255.252  
 ip policy route-map PBR

Best Answer

This feature in JunOS called Filter based forwarding. You can find configurations examples for MX platform here. Example with dual-ISP routing on SRX platform here

Here also working example for SRX platform. We have network, traffic from which should be routed thru non-default route, except local destination networks.

user@srx1400> show route 0/0 exact

inet.0: 450 destinations, 474 routes (450 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 69w5d 17:17:29
                    > to 111.111.111.111 via ge-0/0/1.0

Interface, behind which source addresses are located:

user@srx1400> show configuration interfaces ge-0/0/2.100

description "SRV";
vlan-id 100;
family inet {
    filter {
        input ge-0/0/1.100-in;
    }
    address 192.168.100.1/24;
}

Firewall filter:

user@srx1400> show configuration firewall filter ge-0/0/1.100-in

term inject-default {
    from {
        source-address {
            192.168.100.0/24;
        }
        destination-address {
            10.0.0.0/8 except;
            172.16.0.0/12 except;
            192.168.0.0/16 except;
            0.0.0.0/0;
        }
    }
    then {
        routing-instance ri_fw_injdefault;
    }
}
term default {
    then accept;
}

Routing instance configuration:

user@srx1400> show configuration routing-instances ri_fw_injdefault

instance-type forwarding;
routing-options {
    static {
        route 0.0.0.0/0 next-hop 222.222.222.222;
    }
}

Set up RIB-Groups:

user@srx1400> show configuration routing-options

interface-routes {
    rib-group inet fbf-group;
}
static {
...
}
rib-groups {
    fbf-group {
        import-rib [ inet.0 ri_fw_injdefault.inet.0 ];
    }

}

After all set, lets check routing table for ri_fw_injdefault instance:

user@srx1400> show route 0/0 exact table ri_fw_injdefault.inet.0

ri_fw_injdefault.inet.0: 81 destinations, 81 routes (81 active, 0 holddown, 
0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 38w1d 00:19:55
                    > to 222.222.222.222 via ge-0/0/3.0

Related Solutions

Cisco config example for Policy Based Routing

I would recommend using a route-map for only one purpose (one for nat, another to pbr); mixed use can make for a mess. For NAT, the match interface will apply post-routing -- handy to make conditional nat entries.

The route-map for PBR should use an ACL to match the traffic coming from LAN2 and then set the next-hop to the desired interface with set interface not set default -- or set ip next-hop dynamic dhcp as you won't know the actual gw address. This bypasses / overrides any routing logic that would otherwise send then traffic to your expensive WAN.

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

Full
Outside local country (local IXP, whole own AS + customers seen)
Outside local area (if applicable, like for me it could be 'Nordics')
Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.

If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.

Best Answer

Related Solutions

Cisco config example for Policy Based Routing

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

Related Topic