[Xorp-cvs] XORP cvs commit: xorp/policy xorp/policy/test
Pavlin Radoslavov
pavlin at icir.org
Thu Dec 7 12:00:10 PST 2006
CVSROOT: /usr/local/share/doc/apache/cvs
Module name: xorp
Changes by: pavlin at xorpc.icir.org 2006-12-07 20:00:10 UTC
XORP CVS repository
Modified files:
policy code.cc code.hh code_list.cc code_list.hh
configuration.cc export_code_generator.cc
policy_list.cc policy_list.hh
source_match_code_generator.cc
source_match_code_generator.hh
policy/test policy1.var policy2.var
Log message:
Allow export policy that matches protocol's its own routes.
E.g., now we can have a policy like:
policy {
policy-statement P1 {
term 1 {
from {
protocol: "bgp"
neighbor: 10.10.10.10
}
then {
med: 100
}
}
}
}
This policy can be exported by BGP itself:
protocols {
bgp {
export: "P1"
...
}
}
The result of that policy is that only the BGP routes received from
neighbor 10.10.10.10 will have their MED set to 10.
Previously, a policy like the one above resulted in BGP routes being
reintroduced back from RIB into BGP which created a loop.
Eventually, this modification will affect/fix a number of
BGP policy related Bugzilla entries.
Below are few details about the fix itself:
* The protocol tags inside class Code are kept in two sets:
_all_tags (all tags related to a protocol), and _redist_tags (the
tags that should be send to the RIB so only the routes with that
tags are redistributed into the corresponding protocol).
* Policy tags that are generated by the above example policy code
are not included in the _redist_tags for BGP. This modification
fixes the routes loop issue.
* Previously, inside SourceMatchCodeGenerator::visit_term() the
new generated tag (for a policy term) was unconditionally added
to a route. As a result, for example the following policy (exported
by BGP) would tag and modify all routes, including the routes exported
by other protocol into BGP:
policy {
policy-statement P1 {
term 1 {
from {
protocol: "bgp"
}
then {
med: 100
}
}
}
}
To solve this issue, now inside SourceMatchCodeGenerator::visit_term()
we generate additional policy code that checks the existing tags
of a route before attaching another tag. Only if the existing tags
are a subset of the tags that belong to protocol originating the
routes, then we add another tag to the route.
* Fix the variable information inside test/policy1.var and test/policy2.var.
The original line was used to set the pre-existing tag information for the
sample routes (variable number 1 is hard-coded inside the policy code
to represent tag information):
1 set_u32 123
This information however was ignored and wasn't used to control the
tag attachment (see the above bullet).
Now that the route might not be tagged if the pre-existing tag
information doesn't match the tags that belong to the originating
protocol, we have to set the tag information to something meaningful:
1 set_u32 0
The reason the new variable value works is because tag number 0 is the
first tag chosen by the policy code to attach to a route.
This solution is obviously a hack (e.g., it won't work if the policy
code is modified to choose a different tag number on startup), but
it supplements the original hack of generating/attaching some
tags to the test routes.
Revision Changes Path
1.8 +8 -4; commitid: 13d2f45786ca97ea6; xorp/policy/code.cc
1.6 +21 -6; commitid: 13d2f45786ca97ea6; xorp/policy/code.hh
1.9 +3 -3; commitid: 13d2f45786ca97ea6; xorp/policy/code_list.cc
1.5 +6 -4; commitid: 13d2f45786ca97ea6; xorp/policy/code_list.hh
1.20 +3 -3; commitid: 13d2f45786ca97ea6; xorp/policy/configuration.cc
1.11 +13 -3; commitid: 13d2f45786ca97ea6; xorp/policy/export_code_generator.cc
1.9 +3 -3; commitid: 13d2f45786ca97ea6; xorp/policy/policy_list.cc
1.4 +5 -4; commitid: 13d2f45786ca97ea6; xorp/policy/policy_list.hh
1.14 +26 -4; commitid: 13d2f45786ca97ea6; xorp/policy/source_match_code_generator.cc
1.8 +2 -1; commitid: 13d2f45786ca97ea6; xorp/policy/source_match_code_generator.hh
1.5 +1 -1; commitid: 13d2f45786ca97ea6; xorp/policy/test/policy1.var
1.5 +1 -1; commitid: 13d2f45786ca97ea6; xorp/policy/test/policy2.var
More information about the Xorp-cvs
mailing list