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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
