Can someone tell me what concept I''m missing here. The setup is simple. I have two default routes after ifup operations. I use "ip route del" to remove one, but then decide to add it back. The attempt is refused. Why? # ip route ls 66.95.83.208/28 dev eth1 proto kernel scope link src 66.95.83.210 65.84.205.96/27 dev eth2 proto kernel scope link src 65.84.205.104 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.245 66.0.0.0/8 dev eth1 proto kernel scope link src 66.95.83.210 default via 65.84.205.97 dev eth2 default via 66.95.83.209 dev eth1 # ip route del default via 65.84.205.97 dev eth2 # ip route ls 66.95.83.208/28 dev eth1 proto kernel scope link src 66.95.83.210 65.84.205.96/27 dev eth2 proto kernel scope link src 65.84.205.104 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.245 66.0.0.0/8 dev eth1 proto kernel scope link src 66.95.83.210 default via 66.95.83.209 dev eth1 # ip route add default via 65.84.205.97 dev eth2 RTNETLINK answers: File exists Thanks, Whit
Hello, On Mon, 26 Nov 2001, Whit Blauvelt wrote:> default via 66.95.83.209 dev eth1 > > # ip route add default via 65.84.205.97 dev eth2 > RTNETLINK answers: File existsIt seems you are trying to use alternative routes. Use "ip route append" instead. You can also look at the following URL where the alt routes are extended: http://www.linuxvirtualserver.org/~julian/ look for "Static, Alternative Routes, Dead Gateway Detection, NAT" and also in dgd-usage.txt> Thanks, > WhitRegards -- Julian Anastasov <ja@ssi.bg>
Maybe this also applies to the problem I have been fighting for the last several weeks. I have a VPN situation that requires a Linux router/firewall to route packets back out the same interface on which they came in. Julian, I saw this quote in the website you mentioned: By default, the Linux kernels drop packets with local source address from the forward path as "source martians". This is not controlled from the rp_filter flags. The following patches try to relax this rule and to allow the LVS director to be used as (default) gateway from real servers that send packets with VIP source, i.e. when the same IP is configured on the LVS director. What does this mean? Is this quote telling me that Linux kernels drop packets when their routes to the next hop go out the same interface on which they came in? thanks - Greg Scott -----Original Message----- From: Julian Anastasov [mailto:ja@ssi.bg] Sent: Monday, November 26, 2001 12:51 PM To: Whit Blauvelt Cc: LARTC@mailman.ds9a.nl Subject: Re: [LARTC] RTNETLINK answers: File exists Hello, On Mon, 26 Nov 2001, Whit Blauvelt wrote:> default via 66.95.83.209 dev eth1 > > # ip route add default via 65.84.205.97 dev eth2 > RTNETLINK answers: File existsIt seems you are trying to use alternative routes. Use "ip route append" instead. You can also look at the following URL where the alt routes are extended: http://www.linuxvirtualserver.org/~julian/ look for "Static, Alternative Routes, Dead Gateway Detection, NAT" and also in dgd-usage.txt> Thanks, > WhitRegards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
Hello, On Mon, 26 Nov 2001, Greg Scott wrote:> Maybe this also applies to the problem I have been fighting for the last > several weeks. I have a VPN situation that requires a Linux router/firewall > to route packets back out the same interface on which they came in.You need symmetric routes and rp_filter is one of the solutions. If the problem involves tunnels then rp_filter can cause problems in some situations.> Julian, I saw this quote in the website you mentioned: > > By default, the Linux kernels drop packets with local source address from > the forward path as "source martians". This is not controlled from the > rp_filter flags. The following patches try to relax this rule and to allow > the LVS director to be used as (default) gateway from real servers that send > packets with VIP source, i.e. when the same IP is configured on the LVS > director. > > > What does this mean? Is this quote telling me that Linux kernels drop > packets when their routes to the next hop go out the same interface on which > they came in?No, this is situation where the clusters have hosts that have same (shared) IP configured. The internal hosts have IP that is also configured on their gateway. The patch(es) you mention try to relax the strict rule in the kernel not to allow packet with saddr=local_ip to be considered at all (forwarded or delivered locally). We still drop packets that are locally destined and contain local IP in saddr but we allow such evil packets to be forwarded (forward_shared flag). In short, this is a setup where the LVS director is a gateway for Direct-Route method (you have to read our docs), something similar to NAT topology but without NAT processing, possible only for specific kind of packets, i.e. when the port allocation is not a problem (virtual servers). But you have to explain your problem with more details or may be to show me some URLs if it is explained somewhere.> thanks > > - Greg ScottRegards -- Julian Anastasov <ja@ssi.bg>
Thanks Julian, Does anyone know why the heck "ip route" has been programmed so that it allows something to be deleted that by the same syntax can''t be added? This seems to me to be very, very wrong. Anything that "ip route" shows should be valid syntax, both for deletion and adding. If the utility is more fussy about what can be added than what can be deleted, this is very bad programming. Why has such bad programming been allowed in code that interacts with the Linux kernel? Thanks, Whit On Mon, Nov 26, 2001 at 08:50:33PM +0200, Julian Anastasov wrote:> > Hello, > > On Mon, 26 Nov 2001, Whit Blauvelt wrote: > > > default via 66.95.83.209 dev eth1 > > > > # ip route add default via 65.84.205.97 dev eth2 > > RTNETLINK answers: File exists > > It seems you are trying to use alternative routes. Use > "ip route append" instead. You can also look at the following > URL where the alt routes are extended: > > http://www.linuxvirtualserver.org/~julian/ > look for "Static, Alternative Routes, Dead Gateway Detection, NAT" > > and also in dgd-usage.txt > > > Thanks, > > Whit > > Regards > > -- > Julian Anastasov <ja@ssi.bg>
There is no rule that says there cannot be more than one default - as is clear because it was possible to set up more than one default route to begine with! And the error message, "File exists," does not seem to be true at all, or pertinent. I was not asking to create a file, but a route. So I take it that the "ip" utility doesn''t follow standard procedures and practices regarding syntax and error messages? Why has this been allowed in code that is integrated with the Linux kernel? Was Linus sleeping? Whit On Mon, Nov 26, 2001 at 07:49:50PM +0100, Wojtek Sobola wrote:> simple... default gateway can be only one :> > as the name says ;> > > ----- Original Message ----- > From: "Whit Blauvelt" <whit@transpect.com> > To: <LARTC@mailman.ds9a.nl> > Sent: Monday, November 26, 2001 7:22 PM > Subject: [LARTC] RTNETLINK answers: File exists > > > > Can someone tell me what concept I''m missing here. The setup is simple. I > > have two default routes after ifup operations. I use "ip route del" to > > remove one, but then decide to add it back. The attempt is refused. Why? > > > > # ip route ls > > 66.95.83.208/28 dev eth1 proto kernel scope link src 66.95.83.210 > > 65.84.205.96/27 dev eth2 proto kernel scope link src 65.84.205.104 > > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.245 > > 66.0.0.0/8 dev eth1 proto kernel scope link src 66.95.83.210 > > default via 65.84.205.97 dev eth2 > > default via 66.95.83.209 dev eth1 > > > > # ip route del default via 65.84.205.97 dev eth2 > > > > # ip route ls > > 66.95.83.208/28 dev eth1 proto kernel scope link src 66.95.83.210 > > 65.84.205.96/27 dev eth2 proto kernel scope link src 65.84.205.104 > > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.245 > > 66.0.0.0/8 dev eth1 proto kernel scope link src 66.95.83.210 > > default via 66.95.83.209 dev eth1 > > > > # ip route add default via 65.84.205.97 dev eth2 > > RTNETLINK answers: File exists > > > > Thanks, > > Whit > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://ds9a.nl/2.4Routing/ > >
On Mon, Nov 26, 2001 at 01:22:08PM -0500, Whit Blauvelt wrote:> # ip route del default via 65.84.205.97 dev eth2....> # ip route add default via 65.84.205.97 dev eth2 > RTNETLINK answers: File existsLet me be clear about this: anything that can be deleted, should be able to be added. The "File exists" message is quite wrong, since no file creation has been requested - this is about a route. The error message is worthless, stupid, and just plain wrong. Has Linus really allowed such nonsense to be integrated with the kernel? It''s a totally cool idea, being able to do Cisco-type stuff with Linux. But if the implementation is this lame, it shouldn''t have been integrated at all. Sorry for being pissed off, but please don''t contribute anything to Linux that isn''t done consistently and right! Whit
On Mon, Nov 26, 2001 at 08:12:44PM -0500, Whit Blauvelt wrote:> > RTNETLINK answers: File exists > > Let me be clear about this: anything that can be deleted, should be able to > be added. The "File exists" message is quite wrong, since no file creationThe message text is wrong, but it you need to first understand that most things in Unix are treated like files, whether you realise it or not. Shared memory is now treated like a set of files even and when you fail to create an ''object'' (using a file descriptor), you get an error number 17 (from errno.h) which is defined as EEXIST or "File exists". If the author of the code simply requested the text for the error message in question, "File exists" is what would be returned (do a man strerror or perror). In this particular case, and probably others, the code could be edited to specifically handle the EEXIST condition and instead return "RTNETLINK answers: Route exists". Also, the code returning this error should only return the error if in fact the route already exists. If it can''t be created for another reason, a different error should be returned.> Has Linus really allowed such nonsense to be integrated with the kernel?Do you read C code? If not, Linus'' decisions are probably quite far from your grasp. I appreciate your problem understanding the error in question, but its quite obvious to people who work with this code all the time, even though it should probably be revised to be friendly to others as well.> if the implementation is this lame, it shouldn''t have been integrated at > all.That''s your call. I understand for the most part it so I''m much happier having it integrated than not. -- Michael T. Babcock CTO, FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock/
Hello, On Mon, 26 Nov 2001, Whit Blauvelt wrote:> > # ip route add default via 65.84.205.97 dev eth2 > > RTNETLINK answers: File exists > > Let me be clear about this: anything that can be deleted, should be able to > be added. The "File exists" message is quite wrong, since no file creation > has been requested - this is about a route. The error message is worthless, > stupid, and just plain wrong. > > Has Linus really allowed such nonsense to be integrated with the kernel? > It''s a totally cool idea, being able to do Cisco-type stuff with Linux. But > if the implementation is this lame, it shouldn''t have been integrated at > all.It seems there are not so much people that use the alternative routes. You try to use them without understanding them.> Sorry for being pissed off, but please don''t contribute anything to Linux > that isn''t done consistently and right!Use the time you spend to write emails to read some docs. You can read the ip-cref, you can also read my docs. There are many commands: prepend, append, add. Check where is the difference. "File Exist" is a result of matching some set of keys. append and add have different set of keys that are matched. I agree that add and append are similar but once you understand where is the difference I expect from you to propose another name for these commands. They work for different routes. See in my docs what means "alternative routes", how are they grouped. In short, the alternative routes have equal values for the keys but differ in other values which are not part from the matching set and are something as result values, for example, output device, gateway, etc. As result, the lookup for route is happy when selecting any of the alternative routes in one group but you agree they should be different somehow. These additional values don''t lead to File Exist for append and alternative routes because there must be a reason they to exist at all.> WhitRegards -- Julian Anastasov <ja@ssi.bg>