[LUAU] IP Routing

Brian Chee chee at hawaii.edu
Mon Jun 29 14:10:37 PDT 2009


There is an amazingly good book on "Policy Routing Using Linux" that while
is out of print (check used books like Amazon, etc) is still very pertinent
and hopefully a 2nd edition will be published someday.

"Policy Routing Using Linux" by Matthew G. Marsh from Sams Publishing
ISBN: 0-672-32052.5
$39.99 USD

Also on Safari online at:
http://my.safaribooksonline.com/0672320525?tocview=true

Here is Matthew's online version that has been updated:
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html

If you need to get really serious about routing using Linux...I would
strongly suggest Zebra which is BSD/Linux based routing application that
each protocol is a module you add in. Everything a big Cisco/Juniper can do,
so can Zebra. http://www.zebra.org/

Just to put things into perspective...when I did an advanced Multicast
routing demonstration at the 2000 Atlanta Interop, we had a big server in
the center that allow transitions from DVMRP to PIM/SM SSM on the WAN via
MSDP handshaking as well as PIM-DM on an arm and PIM-SM on another arm. We
found out that the Cisco code purposely disabled transitions from DVMRP to
PIM-SM/SSM to encourage users to drop DVMRP because it was too inefficient.
RouteD/Zebra was our only method to do this demonstration. Now that Mitre
has taken over RouteD our only easily obtained router is Zebra. (If you want
the power point of that project you can get it at:
http://www.ancl.hawaii.edu/classes/mcast/mcast.ppt )

Those cool IOS templates that are floating around that allow you to weight
your WAN connection to allow for multiple WAN connections, and load balance
and failover by rules isn't the domain of $100k routers...Policy Based
Routing is your answer. That's what we used for an emergency communications
system many years ago that had five different WAN connections, each more
expensive to run than the previous. So our weighting also had a financial
ramification.

/brian chee



On 6/29/09 10:17 AM, "Clifton Royston" <cliftonr at iandicomputing.com> wrote:

> [Resending... previous post apparently got lost]
> 
> On Sun, Jun 28, 2009 at 09:42:02AM -1000, Camron W. Fox wrote:
>> Alle,
>> 
>> I have what I thought was a fairly straightforward answer to this
>> but now I'm not so sure.
>> Say you have a HOSTA with four interfaces on four different networks:
>> 
>> eth0 (HOSTA-0) - 10.1.0.0
>> eth1 (HOSTA-1) - 10.2.0.0
>> eth2 (HOSTA-2) - 10.3.0.0
>> eth3 (HOSTA-3) - 10.4.0.0
>> 
>> The default route for HOSTA is 10.1.0.1. It is clear that access to
>> HOSTA from anyone of the listed networks would come in and go out the
>> same interface, i.e. traffic from HOSTB @ 10.1.0.100 goes in and out of
>> HOSTA-0 via eth0.
>> If you are on a different network than exists on the interfaces, say
>> 10.5.0.0, traffic from HOSTC @ 10.5.0.100 goes in any interface but will
>> always go out via the default route on eth0.
>> So the question is, is there anyway to make traffic from HOSTC go in
>> and out the same interface like HOSTA-3?
>> 
>> Best Regards,
>> Camron
> 
>   First, terminology: it appears you are saying you always want traffic
> to HOSTC to go via a specific interface.  That would be a static route
> to HOSTC.
> 
>   To accomplish this, you would set a static route to either HOSTC or
> perhaps (depending) the network it resides on, *via* the interface you
> want it to go back through, i.e. eth3/HOSTA-3.  If you know that
> there's a router on the HOSTA-3 network 10.4.0.0 by which you can reach
> HOSTC, perhaps 10.4.0.1, then you'd set the static route for HOSTC
> (10.5.0.100) or Network C (10.5.0.0/16) to be that router's address. On
> a *BSD that would be something like
>   "route add -net 10.5.0.0 netmask 255.255.0.0 10.4.0.1"
> 
>   If that's what you want, you'd be done at that point (well, once you
> set that to happen at server boot time.)  In theory you can set that
> route to the HOSTA-3 interface instead, but that's a little sketchy;
> you really would prefer your host know what router it's trying to reach
> with it, so that it can send its packets for that network specifically
> via the MAC address (layer 2) of the router it's expecting to send them
> on and can know if the router's down.
> 
>   Now what if the router, or network layout, were to move so that HOSTC
> now reaches you from eth2?  You'll go on blindly trying to reach it via
> eth3 and it will never get there.
> 
>   Well, that's where you start to see the benefits of dynamic routing.
> If you're running a routing daemon on HOSTA, communicating with the
> routers on the network via a standard protocol such as OSPF, then it
> will *know* when the route moves and will go on reaching HOSTC via
> whatever the appropriate interface is.  The downside is that the
> administration of dynamic routing is significantly harder, and if you
> accidentally start broadcasting routes instead of just listening to
> them, you have the potential to really screw up your whole network not
> just your one host.
> 
>   Hope this helps; if not, Tony has offered to help and he's an
> outstanding routing expert.
> 
>   -- Clifton (former LavaNet systems guy)

-- 
Brian Chee
University of Hawai'i at Manoa
School of Ocean and Earth Sciences and Technology (SOEST)
2525 Correa Road, HIG 500
Honolulu, HI 96822
Tel: 808-956-5797






More information about the LUAU mailing list