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

[Pedro Roque Marques]

>>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.