On Thu, 4 Oct 2001, Pekka Savola wrote:
> On Thu, 4 Oct 2001, Matthew G. Marsh wrote:
> > On Thu, 4 Oct 2001, Pekka Savola wrote:
> >
> > > Hi,
> > >
> > > With 2.2.18 I noticed something that looked interesting:
> > >
> > > # /sbin/ip a l dev eth4
> > > 7: eth4: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc pfifo_fast qlen 100
> > > link/ether 00:80:c8:c9:b8:14 brd ff:ff:ff:ff:ff:ff
> > > inet x.y.7.252/24 brd x.y.7.255 scope global eth4
> > >
> > > Note that the interface is not UP. Whether it's promisc or not does not
> > > affect this.
>
> Sorry, I should have articulated this better. There are two issues here:
>
> 1) interface eth4 answers from eth0 (known weak host behaviour, nothing
> new here)
>
> 2) interface address answers to ping etc. even if the interface has been
> brought down.
>
> I should have focused more on 2) in my statement. I believe you answered
> to 1).
Yes and also to 2) - The behaviour you see with 2) is actually what I
(perhaps mistakenly) rely on. IE:
ip addr add 10.1.1.1/24 dev dummy
where dev dummy is used for binding a tunnel or security daemon etcetc.
and the regular interfaces on the system are all 192.168.x.x style
Then on the remote host I add:
ip ro ad 10.1.1.1/32 via 192.168.x.x
where 192.168.x.x is the interface accessable from the other device. In
this way I can use control statements on the mechanism listening on
10.1.1.1 that do not interfere with the regular interfaces of the system.
IE I can use statements such as:
ip rule add from 192.168.y.y dev ${192.168.x.x} prohibit
> > > However, the address is still pingable from outside, through eth0!
And this is the type of behavior that I do use. Where the address is
available through the "real" physical interfaces of the system even if it
is DOWN or bound to dummy etc.
> > > Also noticed the same behaviour in 2.4.10.
> > >
> > > Is this the intended behaviour, probably?
I cannot speak to intention but I do know that this behaviour has worked
since 2.1.38 or so.
> > > One could argue that if interface isn't UP, it shouldn't be able to send
> > > or receive packets at all. I wonder what changing this would break..
I suspect it would break some internal RPDB code... But I really do not
know... Alexey?
> > > --
> > > Pekka Savola "Tell me of difficulties surmounted,
> > > Netcore Oy not those you stumble over and fall"
> > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: mgm@xxxxxxxxxxxxx
WWW: http://www.paktronix.com
--------------------------------------------------
|