Michael, very frustrating that so much noise for a very simple request. I set up multi source routing in 5.3 or so and was astounded at all the negativity on this list and that it could not be done. It will take forever to read the noise in this thread alone. Some said you have to use DHCP.... i could go on. Do not trust that ping -I will work how you would think. Must specify an IP address, not eth0, not eth1. ping -I 10.0.0.1 8.8.8.8 This really is just a few lines per interface. Learn by changing the /etc/sysconfig/network-scripts/ifup-route shell scripts to add logging. echo out variables. There is no need to get iptables involved at all unless doing something very special. i did not want to setup quagga or some form of dynamic routing deamon because of security concerns. i wanted static IP addresses communicating to the ISP on static routes. It is pretty simple. Maybe i can hook up my laptop to 3G and WiFi and Cat6 and make sure i get it working. Please remember to use IP addresses, not names for ping testing. Scrutinize ping results. ping -I 10.0.0.1 8.8.8.8 On Fri, May 3, 2013 at 4:26 PM, Michael Mol <mikemol at gmail.com> wrote: > 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. > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >