[Xorp-hackers] Query on Policy-Based Routing

[Kristian Larsson]

( sorry Andrea for dupes )
On Fri, Aug 12, 2005 at 06:16:06AM +0100, Andrea Bittau wrote:
> 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.
I'm not sure, but I think he means actual traffic
coming from one interface should be forwarded down
one path and traffic from another to some other
path, ie not the actual route.

Something along the lines (on a cisco):
> 
> interface FastEthernet 0/1
>  ip address 192.168.1.1 255.255.255.0
>  ip policy route-map example1
> interface FastEthernet 0/2
>  ip address 192.168.2.1 255.255.255.0
> ...
> ip route 0.0.0.0 0.0.0.0 172.20.1.1
> route-map example1 permit 10
>  set next-hop 10.0.0.1
> 
> 
> traffic from FE0/1 goes to 10.0.0.1 while
> everything else goes to 172.20.1.1
> 
> Correct me if I'm wrong but XORP will never be
> able to do this since it doesn't forward traffic.
> It must be done by the kernel (unless the traffic
> is lifted out into userspace first) and can be
> done in for example Linux using iproute2.
> 
> If this isn't what Ajay needed I kindly ask for
> this mail to be ignored ;)
> 
> //Kristian