[j-nsp] Filter created from bgp route tag ?
ezequiel at ifxnw.com.ar
Thu Aug 25 10:17:41 EDT 2005
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.
On Wed, 2005-08-24 at 22:44, Pedro Roque Marques wrote:
> >>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.
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp