I think you're both in agreement, however violently you try not to be. The question, though, is: *How* do you configure the nodes within the chassis such that the internal IPs (whatever they are) _st
you can do that but you omit the interface addresses - suppose ext net is 10.20.10.1/24, internal is 10.10.10.1/24, no matter what routing policies and rules you put, both interface ips will be visi
Lets end this thread - we are clearly never gonna get to a consensus. Whoever asked the question on how to expose loopback got their answer and you say you are not pushing the patch - so we are all o
What do you mean by "visible"? If you're referring to arp, the arp sysctls are probably adequate, and there's arpfilter if not. Not if you take 10.10.10.1 out of the "local" routing table, and policy
Indeed, I have exactly the same problem with a device that must simultaneously connect to: - the local customer-site ethernet - the local customer-site 802.11 wireless and auto-configure both interfa
1st bug: Customer had the same 10.100.xx.xx/24 net that I had and my inter-system communication wouldn't work, because all my routes got screwed up. (i.e the SNMP sub-agents couldn't talk with the ma
Uh, why? The 127 packets never leave the "box". So you are allowed to use 127/8 but your client cannot break this rule. Why? -- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrel
On Wed, 9 Mar 2005, Jason Lunz wrote: interfaces. I don't know whether policy routing gives enough control to do this in a general fashion; Not easily. The problem is to determine which path packets
they No. If the client uses 127/8 on a linux box, it is just a loopback and will never go out on the wire and the applications (i.e. telnet, ftp, ping, whatever) will just loopback.
They wouldn't do it on the same machine or system. I control my internal system. It's an embedded system which means I have complete control. If they applied it somewhere else on the network, I woul
They wouldn't do it on the same machine or system. I control my internal system. It's an embedded system which means I have complete control. If they applied it somewhere else on the network, I woul
How can I disable the stack processing for the 127 net? Can someone estimate the amount of work needed to do that, and/or point me to the relevant piece of code? That is, I'd like to treat the 127 ne
Hello! Is it really? I've just tried ip addr del 127.0.0.1/8 dev lo ip addr add 127.0.0.1/24 dev lo and `ping 127.1.2.3' is then happily sent along the default route. Have a nice fortnight -- Martin
Well, at least it looks that way to me: svfx:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192
That's like testing on a yugo. Make sure after upgrading to 2.4, you also get iproute2 toolchain. On 2.4.27, once you delete 127.x address from the interface, traffic will go as expected to another r
It's in the local table tgr:axs ~ ip route list dev lo table local broadcast 127.255.255.255 proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 proto kernel scope link src 127.0.0.1 local 127
OK, I think I am getting the picture. 1) looks like what I need may be possible, at least as far as some kernels are concerned. It's not clear that 2.4.25 will work. 2) I only have to perform close t
iproute2 has been the tool of choice since Linux 2.2. ifconfig/route and the old ioctl interface have been only there for compatibility and show only a small subset of the full functionality. That ha
It is clear it will. Not really. Recent (as in, in past 3 years) tools and recent (as in, in past 3 years) kernel. No, not really. 'Route' utility is by definition deprecated. [root@bawx2 ~]# ip rout