>> Christos Zoulas wrote:
>>
>>> In article <412C4B83.4090803@borm.org>,
>>> theo borm <theo_nbsdhelp@borm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I recently converted a machine from 1.5 -> 2.0, and while getting
>>>> rid of everything "useless" in the generic kernel I also switched 
>>>> off
>>>> INET6 support, which resulted in some new behaviour I don't quite
>>>> understand.
>>>>
>>>> The machine in question has three network interfaces, two connected
>>>> to the *same subnet* (public IP), the third connected to a different
>>>> (private IP) subnet. One of the two public interfaces serves as the
>>>> default gateway, the other is just there to catch incoming traffic.
>>>> (The organization I work for insists on having one IP per switch 
>>>> port,
>>>> so the only way to have multiple IP's on the same machine (even when
>>>> these IPs are in the same subnet) is by having multiple network 
>>>> interfaces.)
>>>>
>>>> Normally I could ping all three interfaces. With a current(ish) 2.0
>>>> kernel without INET6 I can no longer ping the non-default-gateway-
>>>> public-IP-network-interface. For all practical purposes this 
>>>> interface
>>>> is dead (from the inside and outside), while the other two 
>>>> interfaces
>>>> are working properly.
>>>>
>>>> When I do a "route flush", all network connectivity breaks.
>>>>
>>>> does this ring a bell?
>>>>
>>>
>>>
>>> I don't think that it is legal to have 2 network interfaces from the
>>> same host connected to the same subnet. I would plug both network 
>>> cards
>>> in the switch to satisfy the organization, keep one of them down, 
>>> and then
>>> give both IP addresses to the second one.
>>>
>>> christos
>>>
>>
>> hm. as long as you have different MAC addresses and IP addresses per 
>> interface, it won't harm. if you have a Sun e.g. (a Quad [Fast] 
>> Ethernet card for instance), you will get four (independent) 
>> interfaces with the *same* MAC -- that is quite a difference. a 
>> managed switch is always cool ;)
>>
>> do you have a managed switch, theo? i guess so. so what do the 
>> counters on each interface say? (this is troubleshooting on layer 1 
>> and 2 of the ISO/OSI model, i know -- but who says that it is a 
>> problem of NetBSD2.0 w/o IP6 support in its entirety?)
>>
> when having INET6 enabled the counters count trafic correctly, without
> INET6 the re2 counter is stuck.
> (both measured just after reboot)
>
> WITHOUT INET6
> Name  Mtu   Network       Address               Ibytes     Obytes
> re0   1500  <Link>        00:50:bf:7e:20:9a        252        588
> re0   1500  192.168.10/24 clusterhead              252        588
> re1   1500  <Link>        00:04:76:8b:fa:a7      72421      15970
> re1   1500  external1/23  narwal                 72421      15970
> re2   1500  <Link>        08:00:20:18:8b:01          0         42
> re2   1500  external2/23  potvis                     0         42
> lo0   33196 <Link>                                1176       1176
> lo0   33196 loopback/8    localhost               1176       1176
>
> WITH INET6
> Name  Mtu   Network       Address               Ibytes     Obytes
> re0   1500  <Link>        00:50:bf:7e:20:9a        252        636
> re0   1500  192.168.10/24 clusterhead              252        636
> re0   1500  fe80::        fe80::250:bfff:fe        252        636
> re1   1500  <Link>        00:04:76:8b:fa:a7    6733002    4697827
> re1   1500  external1/23  narwal               6733002    4697827
> re1   1500  fe80::        fe80::204:76ff:fe    6733002    4697827
> re2   1500  <Link>        08:00:20:18:8b:01     942258        718
> re2   1500  external2/23  potvis                942258        718
> re2   1500  fe80::        fe80::a00:20ff:fe     942258        718
> lo0   33196 <Link>                                   0          0
> lo0   33196 loopback/8    localhost                  0          0
> lo0   33196 localhost     ::1                        0          0
> lo0   33196 fe80::        fe80::1                    0          0
>
> oddly enough pinging the affected external IP from the local machine
> seems to generate trafic on localhost, with just as many bytes coming 
> in
> as going out.... pinging the affected IP from a different machine does
> not generate trafic on localhost.
>
> (and yes, the interfaces' MAC addresses are a bit odd, but these *are*
> the real hardware addresses)
>
> cheers,
>
> Theo

hi,

is the problem still unresolved?

timo

:x!

This life is a test.  It is only a test.  Had this been an actual life,
you would have received further instructions as to what to do and where
to go.