Zugschlusbeobachtungen

Dear Lazyweb, for a long time I have been using iproute2's label feature to assign arbitrary labels to IP addresses configured on Interfaces:

40: int152@dotqa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:b3:01:e5:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.152.254/24 brd 10.1.152.255 scope global int152:98fe8

Recently, this has shown to at least confuse both isc-dhcp-relay (#617258) and dhcp-helper (#617264).

As I have never seen interfaces labels used outside my firewalls (which happen to use ifupdown-scripts-zg2 (Debian PTS)) and ifupdown's rather twisted handling of multiple IP addresses per interface (using Alias Interfaces), I'd like to know whether my usage is a legitimate one and whether there are other uses for interface labels.

At the moment, I'm tempted to remove label support from ifupdown-scripts-zg2 in the next release, or to make it optional. Please comment if you have an opinion.

Das hier muss man in einen ProCurve-Switch reinpasten, damit er danach per ssh konfigurierbar ist:

ip ssh key-size 1024
crypto key generate ssh rsa
ip ssh version 2
ip ssh
aaa authentication ssh login public-key none
aaa authentication ssh enable public-key none
copy tftp pub-key-file <server-address> <file-name.pub> manager

Falle Nummer Eins: Der Kommentar zum Public Key darf kein Leerzeichen enthalten

Falle Nummer Zwei: Auch per ssh nimmt der Switch keine Kommandos auf der Kommandozeile entgegen, "ssh manager@switch show running-config" kann man also leider knicken. Man muss sich dann doch mit expect einen abbrechen, muss aber immerhin keine Klartextpassworte hinterlegen. Aber der passphraselose Key gibt natürlich trotzdem die volle Kontrolle über den Switch.

PlayingExperimenting with arping, I found the following behavior:

$ sudo arping -c 1 10.202.202.254
ARPING 10.202.202.254
60 bytes from 00:0f:20:d4:07:e0 (10.202.202.254): index=0 time=196.934 usec

--- 10.202.202.254 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$ sudo arping -c 1 10.101.2.1
ARPING 10.101.2.1
60 bytes from 00:0f:20:d4:07:e0 (10.101.2.1): index=0 time=168.085 usec

--- 10.101.2.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$

wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don't think it is ok to answer ARP requests for that IP address on "my" interface, as it confuses some "what network segment am I on today" mechanisms.

Is there some /proc setting where I can disable this rather generous ARP behavior?