On 05/01/2013 05:15 PM, Michael H. Warfield wrote:
> On Wed, 2013-05-01 at 16:05 -0400, Michael Mol wrote:
>> I'm attempting to configure source-specific routing so that my servers
>> can exist on multiple subnets from multiple upstream providers.
>
> Kinda curious why you are attempting this without getting involved in
> dynamic routing (BGP)... It's usually someone trying to do multihoming
> or multi-link load balancing on the cheap without involving their ISPs
> (which tends to be expensive as soon as you're talking with them about
> redundant / backup loops, provider independent addresses, and BGP
> peering). Generally equates to "champagne taste on a beer budget" but
> there are exceptions and reasons, as I know from personal experience.
> It often doesn't end well and is unreliable as network conditions
> change. But that depends on your requirements and application. I'm not
> one to judge - just pointing out the pitfalls.
Yup, I know.
Intent is to maintain the old, slow (but has an SLA) connection as a
fallback, and migrate services to the new connection piecemeal.
Meanwhile, the same DNS server on the new connection can be, e.g. "ns3".
The same mailserver can have a new MX on the new connection...likely
prioritized to it.
Inbound services can be load-balanced fairly easily via DNS, if TTLs are
kept low, and records updated in response to link state. It's not
anycast DNS, but it also doesn't require to you get BGP peering and PI
space. (I don't even know if I could *get* IPv4 PI space at this point.
I certainly know I wouldn't be able to if I waited a year...)
>
> I have done this a number of times in the past (mostly for VPN's and
> redundant load-balancing links). You're probably going to have get real
> down and dirty into policy routing rules and tables with iproute2. I
> don't honestly believe you will be able to pull it off with the basic
> stuff provided in the ifcfg-*, route-*, or static-route files (proviso
> below).
>
> I had to do it using completely custom files utilizing "ip rule" and "ip
> route {add|delete} table [n]" subcommands to "ip" to build custom
> matching rules and mapping them to different routing tables containing
> different routes and priorities. In some cases, with OpenVPN VPNs, I
> also had to incorporate iptables filtering commands to mark and match
> packets and interact with the ip rule tables but I doubt you're going
> that deep.
Yeah, I've gone that deep. And a tad deeper. I had almost *everything*
working by hand, and went to figure out how to convert it to idomatic
CentOS network configuration scripts. And took my network down *three
times* because of the script-processing stripping things out.
>
> man ip-rule
>
> --
> In some circumstances we want to route packets differently depending
> not only on destination addresses, but also on other packet fields:
> source address, IP protocol, transport protocol ports or even packet
> payload. This task is called 'policy routing'.
>
> To solve this task, the conventional destination based routing table,
> ordered according to the longest match rule, is replaced with a 'rout‐
> ing policy database' (or RPDB), which selects routes by executing some
> set of rules.
Yup. I went through LARTC before writing a line of code, just to be sure.
Curiously, at least one guy has reported success:
http://sysadminsjourney.com/content/2009/04/15/doing-simple-source-policy-routing-centos/
Now, the only thing different between his setup and mine (apart from my
using ethN:1 instead of ethN, as all three routers hang off the same
ethernet segment) is that were his guide says:
echo "default table CorpNet via 10.0.0.1" >
/etc/sysconfig/network-scripts/route-eth1
My first pass at making my code platform-idomatic effectively was:
echo "default via 10.0.0.1 table CorpNet" >
/etc/sysconfig/network-scripts/route-eth1
(the "table $table" clause in mine was at the end of the line, following
the pattern I'd read in LARTC, rather than near the beginning of the line.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20130501/7f18de4f/attachment-0005.sig>