[Xorp-hackers] [SPAM][RBL+] Re: Issue in implementing PER PEER BGP POLICY. kindly help asap.
Santhosh Sundararaman
santhosh at ku.edu
Sat Nov 25 13:30:01 PST 2006
Hi,
I have finally located what was happening and why.
1. The issue had nothing to do with the RIB's pipeline as I had presumed
earlier. I realized (by removing the RIB policy out filters from the
plumbing) that only the filter that was first used for a route was used
thereafter on all the plumbings irrespective of the filter configuration
in that pipeline.
2. This issues was due to the fact that when a route goes through a
version filter a reference to that filter is maintained in the internal
route message and everytime a route goes through a version filter it is
checked if the route already has a reference to any filters and if so
that filter (referenced in the route) was being applied rather than the
filter config present in policy table of that pipeline. This i learned
was done to identify the the older version of filter that was applied to
a route when a policy (filter) configuration changes and to take an
appropriate decision based on how the route was treated by the older
filter and how it is being treated by the newer filter.
To implement peer specific policies, this has to be slightly
modified so that the filter referenced in the route is not applied to
the route on all the pipelines as each pipeline would have a different
filter configuration. This was not an issue in the normal XORP case as
all the pipelines would have the same filter configuration.
I guess there should be some way of identifying the the recent most
filter that was applied to a route on a per peer basis, so that when a
policy configuration changes for a particular peer add/delete/replace
messages are generated appropriately for a route based on the previous
version of that peer's filter which was applied to that route; to ensure
that the route information in that peer is consistent with the policy
change. I would appreciate any suggestions regarding maintaining peer
specific filter version information for routes.
Thanks
Santhosh.
Santhosh Sundararaman wrote:
> Hi,
> I proceeded to do the following tests which have left me more confused.
>
> I removed the PolicyTableFilterOut from the the pipeline of every
> peer, except RIB (by changing the plumbing's add_peering method). Now
> when I used the filter config mentioned earlier (with neighbor set to
> 172.16.10.3) to setup the PolicyTableFilterOut of RIB, no filtering
> occured. But when I inserted the PolicyFilterTableOut for every peer
> back (even now only the policytable of RIB is set with the config,
> policytables of other peers have no configuration: allowing all
> routes) the routes going to 172.16.10.3 are being blocked although
> this config is only in RIB's pipeline.
>
> So from this it looks to me that the config works only when the RIB's
> policytable has been configured with it, and the at the same time when
> the policytables of other peers are present in the plumbing (just
> thier presence in the plumbing seems to be necassary, whether they
> have been configured with some filter configuration or they are empty
> does not seem to make a difference as long as they are in the
> plumbing). Is there some interaction between the PolicyTableFilterOuts
> of all pipelines with the RIB pipeline's PolicyTableFilterOut.
>
> These results have left me totally confused. Is this a problem or is
> it just the way xorp is supposed to work and I have misunderstood the
> export policy implementation. I presumed that the PolicyTableFilterOut
> of individual pipelines work independed of the RIB pipeline's
> PolicyTableFilterOut or for that matter independed of the entire RIB
> pipeline or the local RIB, isn't that so??
>
> Some one kindly bail me out of this situation.
>
> Thanks,
> Santhosh
>
> Santhosh Sundararaman wrote:
>
>> Hi,
>> I have been trying to implement Per Peer Policy for BGP in xorp by
>> modifying the template file and doing changes in the background
>> (Policy, BGP) as Atanu had suggested in the bugzilla thread. I was
>> able to get the mechanism work for IMPORT policies in BGP. But Im
>> having problems with export policies (for now im trying to apply
>> simple export policies without any redistribution). After poking
>> around a bit I figured out where the problem was, but am not able to
>> understand why the BGP export policy tables are behaving the way they
>> are.
>>
>> Here is what i did. In the bgp.hh file i found that the filters were
>> maintained in the object _policy_filters (of type VersionFilters).
>> And this object is being used as the filter for all the
>> PolicyTableFilterOut (export) tables in the plumbing. After trying
>> several things, I created another object _peer_filters (of type
>> VersionFilters) and now I used this object as the filter for the
>> PolicyTableFilterOut tables of all the pipelines in the plumbing
>> EXCEPT for the RIB's pipeline. The RIB's piplene still uses
>> _policy_filters in its PolicyTableFilterOut.
>>
>> Now irrespective of the filter configuration (in config.boot) the
>> filters seems to be working only when it is applied in the
>> PolicyTableFilterOut of the RIB's pipeline and policies configured on
>> the PolicyTableFilterOut of all other pipelines does not have any
>> effect at all.
>>
>> Here is an example i tried.
>>
>> network4-list "PrefixesFrom105" {
>> elements: "192.168.41.0/24,192.168.42.0/24,192.168.43.0/24"
>> }
>> policy-statement "BlockRoutesFrom105" {
>> term "RoutesFrom105Blocked" {
>> to {
>> neighbor: 172.16.10.3
>> network4-list: "PrefixesFrom105"
>> }
>> then {
>> trace: 1
>> reject
>> }
>> }
>> }
>>
>> Here are my test cases and results
>>
>> Case 1:
>> When this configuration is used to configure _peer_filters (I changed
>> the BGPMain::configure_filter method to configure _peer_filters
>> instead of _policy_filters and i left _policy_filters unconfigured
>> thereby using an empty filter on RIB's export filter table), the
>> filter had no effect despite the fact that 172.16.10.3 is the router
>> id of one of the established peers.
>>
>> Case2:
>> Now i swapped configurations. I applied the above configuration for
>> _policy_filters (effectively applying them to the RIB's export
>> pipeline alone) and left _peer_filters empty (the export filter
>> tables in all other pipelines except RIB will have no configuration
>> and should let all routes through). This is where i noticed
>> unexpected results. I expected this filter to have no effect on
>> routes going to 172.16.10.3, as even though the filter config blocks
>> routes to 172.16.10.3 it is applied only in the export pipeline of
>> RIB and not on others, the other export pipelines had empty filters.
>> But now the routes in the list were blocked from going to
>> 172.16.10.3 but other peer and local RIB received the routes, despite
>> the fact that the filter config was applied only to the RIB's export
>> pipeline.
>>
>> Case 3:
>> Finally i removed the neighbor parameter from the config, letting it
>> take default value. Now, when the config was applied to RIB's
>> pipeline alone and not to others, the routes were blocked from all
>> the peers and from the local RIB. When i swapped the config (with no
>> neighbor set) by applying it to all the export pipelines except RIB's
>> and leaving RIB's export policy config empty, the config had no
>> effect and the routes were getting passed to all the peers and the RIB.
>>
>> From this it appears to me that RIB pipeline's PolicyTableFilterOut
>> seems to be doing the bulk of export filtering (even for other
>> pipelines) and the PolicyTableFilterOut in all other pipelines have
>> no effect on export filtering at all. Have I overlooked something, or
>> have I completely misunderstood Policy implementation in BGP. Kindly
>> help me understand why im experiencing this behavior, is it supposed
>> to work this way: is the RIB's PolicyTableFilterOut supposed to
>> filter routes for all the peer's pipelines?? Kindly help me out!!!
>>
>> Expecting a response asap.
>>
>> Thanks,
>> Santhosh
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>>
>>
>
More information about the Xorp-hackers
mailing list