[j-nsp] Filter-based forwarding on egress - limitations on the MX?

[Tarique A. Nalkhande - BMC]

Clarke,

If I understood your query correctly, IMHO you would also want to explore the option of putting this FBF filter under PFE itself (forwarding-option).

----------------------- sample output -----------------------

MX-960> show configuration forwarding-options family inet filter 
input FBF-Filter;

MX-960> show configuration firewall family inet filter FBF-Filter  
term redirect-term {
    filter redirect-to-Securitybox;
}
term accept-all-without-redirection {
    then {
        count accept;
    }
}

MX-960> show configuration firewall family inet filter redirect-to-Securitybox 
term egress {
    from {
        source-prefix-list {
            <redirected-prefixes-security>;
        }
    }
    then {
        count <xyz>;
        routing-instance redirected-prefixes-security;
    }
}
term ingress {
    from {
        destination-prefix-list {
            <redirected-prefixes-security>;
        }
    }
    then {
        count <xyz>;
        routing-instance redirected-prefixes-security;
    }
}

MX-960> show configuration routing-instances redirect-to-Securitybox 
instance-type vrf;
route-distinguisher <>;
vrf-import <>;
vrf-export <>;
vrf-table-label;
routing-options {
    static {
        route 0.0.0.0/0 {
            next-hop <security-box-ip>;
        }
    }
}

MX-960> show configuration routing-options rib-groups interface-routes                            
import-rib [ inet.0 redirect-to-Securitybox.inet.0]
import-policy import-connected-to-Security


MX-960> show configuration routing-options                                
interface-routes {
    rib-group inet interface-routes;
}

MX-960> show configuration policy-options policy-statement import-connected-to-Security      
term inet.0 {
    to rib inet.0;
    then accept;
}
term connected-to-security {
    from {
        protocol direct;
        interface <x>; <-- Your preferred exit interface 
    }
    to rib redirect-to-Securitybox.inet.0;
    then accept;
}
------------------------- xxxx -----------------------------------

Hope it helps!!!


Thanks & Regards
Tarique Abbas Nalkhande


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Clarke Morledge
Sent: 22 April, 2011 5:29 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Filter-based forwarding on egress - limitations on the MX?

I am trying to wrap my head around the limitations regarding filter-based 
forwarding for egress packets, on the output of a layer3 interface, on 
the MX platform.

Early on in Junos, filter-based forwarding (or "policy-based routing" in 
the Cisco context) you could only do filter-based forwarding on ingress 
into the router.   Now, apparently you can do filter-based forwarding on 
the output interface:

http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-network-interfaces/topic-25474.html

Aside from some limitations with source-class usage filter matching and 
uRPF checks, I am wondering if there are any gotchas here.

Let's say I have an application where I have a security box for scrubbing 
packets hanging off of an MX.  I want to redirect some traffic matching a 
particular filter term along a single egress path out of the router to go 
out instead via a different interface to hit my security box.  However, 
packets along this single egress path might have multiple points of entry 
coming into the router.  It would be difficult to scale putting an input 
filter on all of those different ingress interfaces.  It would be really 
handy and simple to just apply an output filter on the single output 
interface to redirect my traffic.

But are there crazy things that happen under the covers that could cause 
problems?   Is the output filter really just an input filter applied to 
all other interfaces?   What if my ingress packets that follow this path 
come into the router via different shapes and sizes; i.e. straight IP, or 
having an MPLS header, or maybe even a GRE tunnel terminated on the 
router.   Would the output filter still work as I expect?

The documentaton regarding filter-based forwarding on output interface 
suggest that this can be applied to port-mirror traffic, but would this 
also work for my security box redirection application?

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

------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only.