Re: using 2nd network interface - won't try to TX anything
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Sat, 12 May 2007 18:54:01 -0500
On Fri, 11 May 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <ha81i.128$dn2.117@xxxxxxxxxxxx>, Allen McIntosh wrote:
Moe Trin wrote:
phil-news-nospam@xxxxxxxx wrote:
I also find it interesting that your ifconfig output gives
lo Link encap:Local Loopbackas expected, but the routing table says
inet addr:127.0.0.1 Mask:255.0.0.0
169.254.0.0 * 255.255.0.0 U 0 0 0 lo
Fedora seems hang 169.254.0.0 on a random interface.
If Fedora is so brain-dead as to add a LinkLocal/ZeroConf route to the
loopback interface, then someone need to tell the stock-holders of Red
Hat that all the people with clue have left, and it's time to fold the
tents and bail.
A "LinkLocal" or "ZeroConf" address started out as the Apple "Bonjour"
or "Rendezvous" service - a mechanism to allow two sales weasels meeting
in an airport waiting area to trade pr0n^H^H^H^Hsales information by
connecting two computers with a network cable or wireless, but absolutely
no knowledge of networks, IP addresses, or anything like that. Microsoft
discovered the service, and incorporated it into win98 so that when the
MSCE has so fscked up the configuration of the DHCP server that even
windoze won't work, the computers will grab a random address out of
their a$$ and use that to establish a local network connection. It took
seven years to get this massive security hole past the IETF (RFC3927),
but the intent is that when your system (configured for DHCP) can't find
a DHCP _server_ to get an address, it will use an address in the range
169.254.0.0/16. The RFC recommends not having "routable" IP addresses
(which it defines as anything OTHER THAN 169.254.0.0/16 and 127.0.0.0/8)
and ZeroConf or LinkLocal addresses on the same interface. The only
reason I can see to have a "routable" and "LinkLocal" or "ZeroConf"
address range in the routing table on the same interface is to prevent
"Martian" source error messages, which to me makes no sense at all.
But then too, I really have never seen a loopback interface using DHCP,
though I'm sure some MSCE has tried. If you have a box using the
169.254.0.0/16 address range on your _network_, FIX THE DHCP CRAP rather
than hiding the symptoms. Actually at work (where everything uses
static addresses), we monitor for 169.254.0.0/16 addresses to detect
intruders on the network.
ixp1 however is not connected to anything at all and the lines
aren't brought out anywhere on the PCB.
On that PC - does a packet sniffer show anything coming from this "ixp2"
interface?
Wasn't this the interface that was not running?
Yes, but is this the system that the O/P is using?
Old guy
.
- Follow-Ups:
- Re: using 2nd network interface - won't try to TX anything
- From: phil-news-nospam
- Re: using 2nd network interface - won't try to TX anything
- From: phil-news-nospam
- Re: using 2nd network interface - won't try to TX anything
- References:
- using 2nd network interface - won't try to TX anything
- From: phil-news-nospam
- Re: using 2nd network interface - won't try to TX anything
- From: Moe Trin
- Re: using 2nd network interface - won't try to TX anything
- From: Allen McIntosh
- using 2nd network interface - won't try to TX anything
- Prev by Date: Re: using 2nd network interface - won't try to TX anything
- Next by Date: Re: rsync daemon how do I block sites?
- Previous by thread: Re: using 2nd network interface - won't try to TX anything
- Next by thread: Re: using 2nd network interface - won't try to TX anything
- Index(es):
Relevant Pages
|
|
