[j-nsp] Filter-based forwarding outside of inet.0?

Clarke Morledge chmorl at wm.edu
Thu Feb 2 17:54:44 EST 2012

Thanks to Stacy and Hendri, I got this to work perfectly!   This really 

Since it does not hurt to have more examples (as they are non-existent in 
the Junos docs for this particular type of application - Boo Hoo!!!), I am 
including the recipe/configuration solution below......

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187


                                 DefaultRoute  via
Downstream: ----> xe-9/0/0.40 >VirtualRtr<
                                      Hijack via

By default, I have a static route in a routing instance (VirtualRtr) 
sending the default route to  I want to hijack traffic 
matching a particular filter and send the traffic to a different next-hop,

For you Cisco types, this is basically equivalent to using a route-map for 
setting the next hop:

route-map VirtualRtr-Redirect permit 100
  match ip address hijack-acl
  set ip vrf VirtualRtr next-hop

Whereas in the Cisco world, you would need to create an ACL and apply that 
with the route-map to the incoming interface, in Junos you create a filter 
and apply the filter to the interface:

[edit firewall family inet filter fbf-redirect-filter]
term t1 {
     from {
         address {
     then {
         routing-instance fbf-test;
term t2 {
     then accept;

[edit interfaces xe-9/0/0 unit 40]
vlan-id 40;
family inet {
     filter {
         input fbf-redirect-filter;

At this point, Junos is more complex as it adds a layer of abstraction 
with the concept of rib-groups.  You create your rib group by importing 
FIRST the table belonging to your virtual router and SECOND the table for 
the forwarding instance that has the next-hop specified:

[edit routing-options]
rib-groups {
     fbf-rib-test {
         import-rib [ VirtualRtr.inet.0 fbf-test.inet.0 ];

So here is the "forwarding" routing instance that defines the next-hop IP. 
But you'll need to make sure you can resolve the next-hop, so you 
associate the "interface-routes" with the rib-group you've created within 
the virtual routing instance:

[edit routing-instances fbf-test]
instance-type forwarding;
routing-options {
     static {
         route next-hop;  ## PBR-like next-hop

[edit routing-instances VirtualRtr]
instance-type virtual-router;
interface xe-9/0/0.40;
interface xe-11/0/0.40;
interface irb.42;
routing-options {
     interface-routes {
         rib-group inet fbf-rib-test;
     static {
         route next-hop;  ## Normal next-hop

In my case above, the is hanging off of the irb.42 
interface.   Everything resolves in the routing tables:

show route table VirtualRtr          *[Static/5] 25w4d 07:20:38
                     > to via xe-11/0/0.40

show route table fbf-test          *[Static/5] 00:54:31
                     > to via irb.42

And also you can verify the forwarding entries (my IRB is part of a vpls 
interface, hence the reference to the lsi):

show route forwarding-table table VirtualRtr
Routing table: VirtualRtr.inet
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     0 0:23:9c:10:10:40   ucst  1836    39 
default            perm     0                    rjct   643     2         perm     0                    dscd   641     1

show route forwarding-table table fbf-test
Routing table: fbf-test.inet
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     0 0:10:db:ee:10:0    ucst  4721     3 
default            perm     0                    rjct  7005     2         perm     0                    dscd  6937     1

More information about the juniper-nsp mailing list