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

Stacy W. Smith stacy at acm.org
Wed Feb 1 13:23:52 EST 2012


Hi Clarke,

1) The rib group must be defined under the main instance [edit routing-options rib-groups] .
2) The import-rib line in the rib group definition must list the VRF routing table first, and the FBF routing table second.
3) The rib group must be applied within the VRF [edit routing-instances VRF [edit routing-options interface-routes rib-group inet].


Here's an example, using instance-type virtual-router, but the same principles should apply to instance-type vrf:

1) Traffic enters the foo routing-instance on fe-2/0/2.10.
2) If traffic is sourced from 192.168.1.3/32 the next hop is 192.168.3.2 via fe-2/0/2.30.
3) If traffic is source from any other address, the next hop is 192.168.2.2 via fe-2/0/2.20.

user at host> show configuration interfaces fe-2/0/2 
vlan-tagging;
unit 10 {
    vlan-id 10;
    family inet {
        filter {
            input bar;         <<<<<<<<<<< firewall filter applied to ingress traffic
        }
        address 192.168.1.1/24;
    }
}
unit 20 {
    vlan-id 20;
    family inet {
        address 192.168.2.1/24;
    }
}
unit 30 {
    vlan-id 30;
    family inet {
        address 192.168.3.1/24;
    }
}

user at host> show configuration routing-options            
rib-groups {
    fbf {                          <<<<<<<<<<<<<<<<<< rib group defined in master instance
        import-rib [ foo.inet.0 fbf.inet.0 ];  <<<<<<<<< vr table 1st, fbf table 2nd
    }
}

user at host> show configuration routing-instances  
fbf {                                         <<<<<<<<<<<<<< forwarding instance
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 192.168.3.2;  <<<<<<< next-hop only reachable via foo.inet.0
        }
    }
}
foo {                                       <<<<<<<<<<<<< vr instance
    instance-type virtual-router;
    interface fe-2/0/2.10;     <<<<<<<<<<<<< ingress interface
    interface fe-2/0/2.20;     <<<<<<<<<<<<< 1st egress interface
    interface fe-2/0/2.30;     <<<<<<<<<<<<< 2nd egress interface
    routing-options {
        interface-routes {
            rib-group inet fbf;  <<<<<<<<<<<<< copy interface routes to fbf.inet.0 using the fbf rib group 
        }
        static {
            route 0.0.0.0/0 next-hop 192.168.2.2;  <<<< default route for traffic that's "accepted" by the bar firewall filter
        }
    }
}

user at host> show configuration firewall 
family inet {
    filter bar {
        term 1 {
            from {                         <<<<<< criteria for traffic that should be forwarded via FBF
                source-address {
                    192.168.1.3/32;
                }
            }
            then {
                routing-instance fbf;   <<< using fbf.inet.0 for forwarding lookup
            }
        }
        term 2 {
            then accept;   <<< accept everything else and use default foo.inet.0 for forwarding lookup
        }
    }
}

user at host> show route table foo 

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

0.0.0.0/0          *[Static/5] 00:45:34
                    > to 192.168.2.2 via fe-2/0/2.20   <<<<<<<<<<< default route for non fbf traffic
192.168.1.0/24     *[Direct/0] 00:57:20
                    > via fe-2/0/2.10
192.168.1.1/32     *[Local/0] 00:57:20
                      Local via fe-2/0/2.10
192.168.2.0/24     *[Direct/0] 00:57:20
                    > via fe-2/0/2.20
192.168.2.1/32     *[Local/0] 00:57:20
                      Local via fe-2/0/2.20
192.168.3.0/24     *[Direct/0] 00:57:20
                    > via fe-2/0/2.30
192.168.3.1/32     *[Local/0] 00:57:20
                      Local via fe-2/0/2.30


user at host> show route table fbf    

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

0.0.0.0/0          *[Static/5] 00:37:17
                    > to 192.168.3.2 via fe-2/0/2.30  <<<<<<<< default route for fbf traffic
192.168.1.0/24     *[Direct/0] 00:37:17
                    > via fe-2/0/2.10
192.168.1.1/32     *[Local/0] 00:37:17
                      Local via fe-2/0/2.10
192.168.2.0/24     *[Direct/0] 00:37:17
                    > via fe-2/0/2.20
192.168.2.1/32     *[Local/0] 00:37:17
                      Local via fe-2/0/2.20
192.168.3.0/24     *[Direct/0] 00:37:17
                    > via fe-2/0/2.30
192.168.3.1/32     *[Local/0] 00:37:17
                      Local via fe-2/0/2.30


Hope this helps. If the FBF next-hop is across the MPLS core and learned via MP-BGP, you might have to get a little more creative in the application of your rib-group, but otherwise the same concepts should apply.

Let me know if you hit any more roadblocks.

--Stacy


On Jan 31, 2012, at 4:16 PM, Clarke Morledge wrote:

> I am still trying to wrap my head around FBF, and I am stuck on how to achieve a Cisco-like PBR forcing a packet that matches a set of conditions to go to a different next-hop inside a VRF.  The problem I have is when the new next-hop can only be resolved within the VRF, NOT the default routing instance (inet.0).
> 
> Let's say I am trying to create this forwarding instance to change the default route:
> 
> [edit routing-instances fbf-test]
> HonkinBigMx# show
> instance-type forwarding;
> routing-options {
>    static {
>        route 0.0.0.0/0 next-hop 192.168.255.1;
>    }
> }
> 
> I need to create a rib group where 192.168.255.1 can be resolved (correct?).  It can be resolved in a virtual routing instance (a VRF) called test.inet.0 where I need to insert via a filter the changed default route next-hop for PBR forwarding purposes.  THe 192.168.255.1 can not resolve in inet.0 because it does not live there.
> 
> If I try to create a rib group:
> 
> interface-routes {
>    rib-group inet fbf-rib-test;
> }
> rib-groups {
>    fbf-rib-test {
>        import-rib [ fbf-test.inet.0 test.inet.0 ];
>    }
> }
> 
> The Junos compiler complains:
> 
> [edit routing-options interface-routes]
>  'rib-group'
>    fbf-rib-test: primary rib for instance master was not found in ribgroup configuration.
> error: configuration check-out failed
> 
> I try to define the interface-routes at in the test.inet.0 routing instance stanza (which is where I think it should be defined anyway), and I get a similar complaint.
> 
> In reading the docs, they insist that I must import inet.0 into the rib group, even though the next-hop can not be found to resolve there. Furthermore, I can only define a rib-group in the default routing instance part of the config and not in the routing-instance part of the config.
> 
> What am I missing here and/or how can I workaround this limitation?
> 
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp




More information about the juniper-nsp mailing list