[Xorp-hackers] Query on Policy-Based Routing

[Andrea Bittau]

On Thu, Aug 11, 2005 at 09:18:10PM -0500, Ajay Anil Mahimkar wrote:
> I looked at bgp.tp and policy.tp. Could someone please let me know whether
> (network4:ipv4net) in the "to" clause implies the destination network
> prefix. Also, in policy.tp, network4:ipv4net is present in both "from" and
> "to". Could someone elaborate on this?

"to" means: match these attributes just before the route is leaving the protocol
/ about to be advertised.  For example:

from {
	protocol: "static_routes"
}
to {
	neighbor: 10.0.1.1
}
action {
	localpref: 100
}

Using this as a BGP export policy, it means that all static routes will be
redistributed only to the BGP peer 10.0.1.1, and will have a localpref set to
100.


network4 will match the prefix of the route, both in from and to.  i.e.

from {
	network4: 10.0.0.0/24
}

and

to {
	network4: 10.0.0.0/24
}

are equivalent.  The only difference is that the matching occurs in a different
stage [from in the input side, to in the output side].
I can't think of an example where using from vs to for network4 is useful.

If you want to know more about what a "variable" [such as network4] really
means, read the _varrw.cc files.  For example bgp_varrw.cc and look how network4
is read / written to.

> Also, is this the correct way to set LOCALPREF for say a destination
> network prefix,
> 
> policy {
> 	policy-statement next-hop-selection {
> 		term 1 {
> 			to {
> 				network4: 128.43.0.0; (example destination
> prefix)
>    			}
> 			then {
> 				localpref: 300
> 			}
> 		}
> 	}
> }

Yes this should work [you need a /XX in the prefix].  This will set the
localpref to 300 on all routes passing through BGP.  Depending on whether it is
import or export filter, the actual change in localpref will occur pre/post
decision.

> One more question, if in the nexthop4 in the "then", if i specify an
> address that is not directly connected, would IGP be used to find the
> next hop interface for this nexthop4 address ?

If used as an import filter, then the nexthop resolver should figure out what's
going on.  If used as an export filter, it will blindly be advertised with that
nexthop.

> Also, currently do you support traffic classification based on interfaces.
> For example, if i want to select route based on the interface on which i
> received packet, like on interface eth1, i prefer a certain next-hop while
> on eth2, a different next-hop is preferred. Is this currently supported ?

No but it's a good one to add... especially for RIP i guess.
[I don't think BGP cares about interfaces... only about peers]


I'll write a crude policy documentation today in the user-manual, so you might
want to look in CVS tonight GMT time---hopefully it will be there.