|
Hi Joe,
so drugphish is back on the internet? Good to see
Yep, it's alive and kicking, although we haven't moved everything yet.
will go fix up the text.
Cool, thanks. Sorry if I didn't explain it correctly the first time
years ago ;).
o the basic problem with route/netstat -rn is, that they only see the
main table, which is rather limited.
o iproute2 very well knows the notion of ip aliases by using labels just
like ifconfig.
I didn't realise this. I thought the idea was to abandon aliases/labels
and assign new interfaces for each IP. I assumed labels was backward
compatibility feature only.
Well, look at it this way: ifconfig gives you the (wrong) impression
that eth0:0 is an interface just as others in the list of 'ifconfig -a',
which is not true. The tools from the iproute2 package know it better
and displays the correct entity relationship between aliases/labels and
their corresponding physical interface.
Example:
laphish:~ # ifconfig -a | grep -A2 eth0
eth0 Link encap:Ethernet HWaddr 00:20:E0:68:71:3A
inet addr:172.23.2.131 Bcast:172.23.255.255 Mask:255.255.0.0
inet6 addr: fe80::220:e0ff:fe68:713a/64 Scope:Link
--
eth0:0 Link encap:Ethernet HWaddr 00:20:E0:68:71:3A
inet addr:10.98.43.233 Bcast:10.98.43.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
--
eth0:foo Link encap:Ethernet HWaddr 00:20:E0:68:71:3A
inet addr:10.23.7.233 Bcast:10.23.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
laphish:~ #
Sure, one could argue that all HWaddr of those "interfaces" are the same
and thus something with the interpretation of them being _real_ physical
interfaces must be fishy. But it gives you the wrong idea of connection
or entity relationship between link and ip layer.
Now let's compare the same output for iproute2:
laphish:~ # ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:20:e0:68:71:3a brd ff:ff:ff:ff:ff:ff
inet 172.23.2.131/16 brd 172.23.255.255 scope global eth0
inet 10.23.7.233/24 brd 10.23.7.255 scope global eth0:foo
inet 10.98.43.233/24 brd 10.98.43.255 scope global eth0:0
inet 10.239.10.1/24 brd 10.239.10.255 scope global eth0
inet6 fe80::220:e0ff:fe68:713a/64 scope link
laphish:~ #
As you can see we have a physical interface (link layer entity) called
eth0 and associated with this interface we have 5 (not 4 like with
ifconfig) IP addresses. And you can certainly well spot the labels which
in ifconfig were displayed as independant interfaces at the end of each
line starting with inet, right?
Plus there you certainly noted that in the second output we have one
additional address which was not shown in the ifconfig output but is
very well routable and _is_ a valid configuration. I simply didn't want
to put an alias there.
It's then better understandable that tools like ipchains and iptables
and their underlying state machine are better off matching for ip
addresses and the _one_ physical interface those are attached to then
trying to fiddle around with a label that is optional and doesn't give
you real valuable information. Additionally with iproute2 you have a
better approach to conceptional integrity which is one of the key
ingredients of architectures in that you say that even if I have
multiple addresses for one interface I still send out the packet through
the physical interface and not through a labeled, aliased or virtual
interface.
ifconfig is the best example of a "hiding complexity" tool and hiding
complexity is a concept the software industry has not yet reached to the
extend we can trust on, and thus ifconfig is broken by design.
The reasons why people still use those deprecated tools are:
o All other Unices still have those and it worked reliably for 10+ years
o Most Linux Distributors except (notably) SuSE haven't switched their
network setup to the iproute2 concept yet.
o Documentation was seriously lacking and the tools are ... uhmm to a
certain degree complex and incoherent in their syntax and semantics.
It's not up to the tool to decide if labels work or
not. The misconception people have with ip aliasing is that people
think an aliased interface is a logically separated interface while
it is _not_. And this is the case since 2.1.128 or so.
o ipchains doesn't recognize alias neither because since the _2.2.x_
kernel we moved to the iproute2 architecture, not in the 2.4.x as
the howto lists.
will fix, I don't remember when the changeover occured.
Between 2.1.126 and 2.1.138 IIRC but this is years ago and my brain
normally works on a circular buffer with 24 hours of capacity.
+ if you add secondary ip addresses without a label (alias interface)
ifconfig is confused and doesn't print the information
OK
As shown pretty effectively above.
+ if you add rules for branching into different routing tables than
the main routing table, route or netstat -rn will not show you those
routes. This also the case for blackhole, throw, unreachable and
prohibit routes.
my problem with iproute2 is the horrible syntax.
It's impossible to script. All this other stuff is fine by me.
Look at my script and you'll see that it's really almost not scriptable.
I had to solve it by writing really gross bash constructs and by using
external tools ;).
BUT, it solves some of architectural principles, such as separation of
concern, correctness, flexibility, conceptional integrity, coupling and
cohesion! You are given two tools to maintain almost everything network
related. (I'm aware that iptables/netfilter and mii-tool, ethtool are
also network related)
If you guys are interested I'll offer my first semi-official release of
some of the replacement tools I've written for ifconfig/route. You can
download them from (just uploaded):
http://www.drugphish.ch/~ratz/iproute2/
great. I'll put it in the HOWTO
Ok, but the link might change if I find time to put it to a more
appropriate place on drugphish.ch.
Cheers mate,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
