[j-nsp] Filter created from bgp route tag ?

[Ezequiel Carson]

Pedro,

            Can i use this for emulating the Cisco's QPPB feature.  Im
trying to apply a policer for the incomming traffic when the
destionation ip address matches with a BGP community.

            I understand that Junos can not do this in a easy way, since
the policer is applied before the routing lookup.

            Any idea?

Thanks
Ezequiel
On Wed, 2005-08-24 at 22:44, Pedro Roque Marques wrote:

> >>Hello,
> >>
> >>I am wondering if there is a way with a juniper create a 
> >>filter to allow only traffic which source or/and destination 
> >>ip is in the routing table with a particuliar bgp tag ?
> 
> SCU / DCU.
> 
> You can tag a route w/ a source-class and a destination class and do:
> 
>      Src Lookup -> FTF filter -> Dst lookup -> [post dst filter]
> 
> source lookup will mark a route with a "source class".
> dst lookup will remark a route with a "destination class", this will 
> overwrite the source class value (same hw register).
> 
> So that is why you may want to filter via FTF (aka "forwarding options
> family inet filter input).
> 
> Then the [post dst filter] can be:
> a) on M series, the output interface filter.
> b) on T-series (incld m320), [forwarding-optins family inet filter 
> output] in a release that has it available...
> 
> >>
> >>The reason is that I want to do in and ouband filtering. atm, 
> >>I am using prefix-list but it require maintenance for each 
> >>new customer you add to your config. All my customer (and my 
> >>originated) routes are tagged when learned, so I should be 
> >>able to say that if a packet arrives to an ebgp router and 
> >>does does not have one of those tag, it can not be legit.
> 
> >>I already have "routing-options forwarding-table 
> >>unicast-reverse-path feasible-paths" but I do not think it 
> >>will catch all the possible cases.
> 
> That may be more appropriate for what you are trying to achieve... plus 
> it does something you can't do w/ a route tag. It allows you to accept 
> traffic in a environment in which your traffic happens to be assymetric 
> to your customer... i.e. if you accept MEDs from your customer.
> 
> "feasible paths" means that the list allowed input interfaces for RPF 
> includes both the active route an other feabible BGP paths, even if not 
> preferred... that would be the case when you have multiple routes w/ 
> different MEDs from a customer.
> 
> RPF check and an SCU lookup are very similar operations as far as the 
> forwarding engine is concerned. The latter results in seting a "class" 
> the former in performing an input interface check.
> 
>  From your problem description, RPF sounds the preferred approach.
> 
>    Pedro.
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>