[CentOS] Configuring source-specific routing

[Michael Mol]

On 05/03/2013 03:24 PM, Michael H. Warfield wrote:
> On Wed, 2013-05-01 at 17:52 -0400, Michael Mol wrote:

[snip]

> 
>> 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
> 
> Ok...  Wow...  If that's the only difference between his description and
> what you did, you certainly left A LOT out.  He's using both rules and
> tables neither of which you made any mention of in your original post.

I tried it both ways, honestly. I've been blasted (postfix) or ignored
(samba) more than a few times in other environments for providing too
much information, so I didn't think it wise doing a writeup of both
approaches. Can't win. Can't even break even...

> 
> At this point, having read that article, I will eat my earlier words
> (not the first time and certainly won't be the last time).  I guess you
> can now do this using the standard files, it's just that I haven't done
> it in so long that you couldn't do it back then (my excuse and I'm
> sticking with it).  Following his description, I could easily reproduce
> my old setups using ifcfg-ethN, rule-ethN, and route-ethN.  I'm
> impressed.  I don't need it any more but - nice...  That makes it a lot
> easier than what I had to figure out.

I was going to ask you how you tied in your manual script...

> 
> Ok...  So, I'm assuming you properly set up the rules-ethN file as well
> (and the proper entry in /etc/iproute2/rt_tables?  You made no mention
> of that in your OP.  That's a very crucial bit there.

So, this is interesting. I'd read that you could use a command like

ip route add 1.2.3.4/32 dev eth0 via 10.1.0.1 src 10.1.0.12 from 4.3.2.1/24

with the "from 8.3.2.1/24" portion as part of the IP command, but that
using tables was usually done because it was easier.

What's bizarre is that I could have sworn I had this type of rule even
working. But when I run it on my laptop, and follow up with "ip rule
show", the "from X" clause is gone.

This calls into question everything else I was convinced I had working,
too. But I do know my 'table CorpNet' approach worked when applied
manually, but not when I tried converting it to route-ethN. I won't be
able to try it again for a while, either, but I've got a hunch why it
didn't work.

> 
> Also, in your OP you mentioned this:
> 
> On Wed, 2013-05-01 at 16:05 -0400, Michael Mol wrote:
>> I've created a route-eth0:1 file that looks roughly like this:
>>
>> 10.0.0.1 dev eth0:1 \
>>   src 10.0.0.2 \
>>   from 10.0.0.0/29
>>
>> default via 10.0.0.1 dev eth0:1 \
>>   src 10.0.0.2 \
>>   from 10.0.0.0/29 
> 
> You're not showing table numbers or names there so it's not clear if you
> are using different route tables or not (which you MUST do and associate
> them with appropriate match rules).

Yup. See above where I discover "from a.b.c.d" isn't a valid clause to
attach to the ip command. As finicky as that command is, I'm
disappointed it didn't throw an error.

> 
> According to "man ip-route" on my router the "from" stanza is not valid
> in a "route add" (route-ethN files) and in a "route ls" is only
> applicable to "cloned" routes.  What you wrote can not literally work,
> by my reading of the "ip" man pages.

Yup. I just re-read through to double check, when my manual invocation
on my laptop didn't work.

> 
> You get the source matching from the "rules" not the "routes".  You
> haven't mentioned (or acknowledged) anything about them but they are
> crucial (as are the use of multiple tables).  What did you set up for
> your match rules?  No match rules, then only the default and local
> tables are going to be used.  Your "from" specifier goes in your rules,
> not your routes.

I hear you. I just wish I'd documented my first approach (using tables)
better; I'm sure it was a silly error, and I'm getting more sure it was.
I'd rather have had someone thump me over the head and point out a
simple error than spend three days arguing over whether or not
source-specific routing makes sense.

> 
> When I look at my route tables, I see src associated with an appropriate
> route.  I don't see any "from" matches because they are not in the route
> tables they're in the rules.  You also have to look at "ip rules ls".
> That's where your "from" is going to show up and then tell you what
> table it's going to use as its routing table.
> 
>> 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.)
> 
> Ok, so you are using the table named "CorpNet" which you must have added
> to /etc/iproute2/rt_tables in advance (his step 1) otherwise you can
> only use table numbers.  The position of the "table CorpNet" should make
> no difference.  Have you added a corresponding match rule (his step 3)?
> He defines "CorpNet" as table 200.
> 
> It looks like, if you did everything he describes in that article, it
> should work.  I've done this manually and what he describes there
> exactly matches what I would expect to work.  You really haven't given
> us the complete picture of what you did (or if you did, you left out a
> couple of steps).  Obfuscate the addresses and names if you must but you
> need to be clearer on the contents of all the configuration files.
> 
> /etc/iproute2/rt_tables
> /etc/sysconfig/network-scripts/ifcfg-eth0
> /etc/sysconfig/network-scripts/route-eth0
> /etc/sysconfig/network-scripts/rule-eth0

I'm thinking my problem must have been in the rule file. If I had to
guess, I didn't add the file, but was instead counting on the rule I'd
put in manually to be sufficient to pick it up. I imagine restarting the
interface flushed the rule list.

> 
> I'm also not real sure how this works with additional addresses like
> eth0:N.  Not sure if you need these in the parent device or the alias
> device.  Looks like putting under the alias interface should be fine. 

I'm not fond of the alias devices, but you might call it part of the
"coding style" of this network.

> 
> Regards,
> Mike

Thank you for the responses. Once I get this working, I'll certainly
report back. But I'm going to guess it might be at least a few weeks
before I can poke it again. Things need to settle down, first.



-------------- 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/20130503/37563b5d/attachment.sig>