[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