[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
helped.
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 192.168.0.1
^
|
|
xe-11/0/0.40
|
Downstream: 192.168.99.2 ----> xe-9/0/0.40 >VirtualRtr<
|
irb.42
|
|
v
Hijack via 192.168.255.1
By default, I have a static route in a routing instance (VirtualRtr)
sending the default route to 192.168.0.1. I want to hijack traffic
matching a particular filter and send the traffic to a different next-hop,
192.168.255.1.
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 192.168.255.1
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 {
192.168.99.2/32;
}
}
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;
}
address 192.168.99.1/30;
}
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 0.0.0.0/0 next-hop 192.168.255.1; ## 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 0.0.0.0/0 next-hop 192.168.0.1; ## Normal next-hop
}
}
In my case above, the 192.168.255.1 is hanging off of the irb.42
interface. Everything resolves in the routing tables:
show route table VirtualRtr
0.0.0.0/0 *[Static/5] 25w4d 07:20:38
> to 192.168.0.1 via xe-11/0/0.40
show route table fbf-test
0.0.0.0/0 *[Static/5] 00:54:31
> to 192.168.255.1 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
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 0 0:23:9c:10:10:40 ucst 1836 39
xe-11/0/0.40
default perm 0 rjct 643 2
0.0.0.0/32 perm 0 dscd 641 1
show route forwarding-table table fbf-test
Routing table: fbf-test.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 0 0:10:db:ee:10:0 ucst 4721 3
lsi.1048729
default perm 0 rjct 7005 2
0.0.0.0/32 perm 0 dscd 6937 1
More information about the juniper-nsp
mailing list