Many thanks for the replies which cleared my befuddled head! Nothing like
some outside observations to help when your perception is distorted.
The problem I had was that (on a multi interfaced ultra machine) an arp
request for a host on the qe0 interface received on interface le0 was not
responded to by the le0 interface.
As was clearly pointed out, the arp request is a 'per wire'
protocol, thus ignored correctly by the le0 interface.
Thus, either the routing was hosed or a proxy arp response was
required to correctly inform the client where to send the packet.
In this case the client generating the arp requests was a
cisco router that was running OSPF and not RIP, thus
never had obtained the routing which would have had it
send the qe0 IP destination packet directly to the
le0 interface. Routed on the ultra was running, but
the cisco wasn't listening.
Having seen the unanswered arp request I kept trying to
fix that, but that was not really the solution.
The follow up question:
Is there an OSPF available for Solaris? Else
I have to get someone to turn on RIP or (shudder) hard code
routes in the cisco.
It was observed by wezel@bio.vu.nl that tinkering with ifconfig
after the initial boot can cause some enet driver problems...
I have had this experience before, with 2.3? as I recall.
Some errors in the original post; the subnets were
distinct class "B" subnetted, not class "C" as I typed.
Many thanks to those below for their patient and helpful
replies!
Daniel.Blander@ACSacs.com
casper@Holland.Sun.COM
wezel@bio.vu.nl
mshon@sunrock.East.Sun.COM
####### ORIGINAL QUERY ##########
I have a quad ether board on an ultra/solaris 2.5 box.
The machine is set to act as a router between le0 and qeXX's.
There is no arp reply generated for arp requests on the le0
wire for the quad interface(s) IP addresses ( qeXX). Snooping
shows the arp requests generated by other hosts are present on
the wire but go unanswered by the routing host.
Another machine supplying a proxy arp for the qe interfaces
allows communication of other machines thru the interfaces.
The proxy supplies the le0 IP.
Manually setting up the routing works, locally on the host
the routing works, there is just no arp response. Netmasks
discriminate the interfaces as different class C domains,
ie 0Xfffffc00, all under one class B domain.
A look through the ndd effects has not enlightened me --
I don't see anything applicable that is not set OK.
The arp table shows the interfaces correctly published.
I did not see anything related to arp in the faq,
It's a nice puzzle, but I really need to get it to
work without the proxy RSN!
Thanks in advance for any brain cycles anyone can
spare or pointing out the obvious to me!
***** Bob Hayes <bob@cs.wwu.edu> *****
########################################
>From Daniel.Blander@ACSacs.com Tue Feb 13 22:56 PST 1996
Return-Path: <Daniel.Blander@ACSacs.com>
Received: from sprite (sprite.acsacs.com) by reef.cs.wwu.edu (5.0/SMI-SVR4)
id AA24323; Tue, 13 Feb 1996 22:56:19 -0800
Received: by ACSacs.com
id AA04177; Tue, 13 Feb 1996 22:55:28 -0800
Date: Tue, 13 Feb 1996 22:55:28 -0800 (PST)
From: "Daniel J Blander - Sr. Systems Engineer for ACS" <Daniel.Blander@ACSacs.com>
X-Sender: phaedrus@ferrari
To: bob hayes <bob@reef.cs.wwu.edu>
Subject: Re: No arp reply, multi interface?
In-Reply-To: <9602131719.AA22276@reef.cs.wwu.edu>
Message-Id: <Pine.SOL.3.91.960213225036.4140K-100000@ferrari>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2784
This is (at least from my glance through your writings) standard
behaviour. Each interface is treated as a seperate network - packets
are not bridged but routed. The machine will answer pings to the
interfaces but not arp's. If the routing is set up, then the interfaces
will get the information passed at the higher level (network level).
The OS treats each interface as a router port (just like a Cisco would -
good old numbered interfaces) the only way for them to talk to each
other is for internal routes to each interface - which if you look
at netstat -rn you will see each interface routed using metrics of 0
(local). But arps are physical layer and can not jump across the OS.
Ethernet addresses are not passed across the interfaces. The sun's
are set in their OS to act as routers not as bridges....
Its just normal..... *-={:-)
On Tue, 13 Feb 1996, bob hayes wrote:
> Date: Tue, 13 Feb 1996 09:19:43 -0800
> From: bob hayes <bob@reef.cs.wwu.edu>
> To: sun-managers@ra.mcs.anl.gov
> Subject: No arp reply, multi interface?
>
> I have a quad ether board on an ultra/solaris 2.5 box.
> The machine is set to act as a router between le0 and qeXX's.
>
> There is no arp reply generated for arp requests on the le0
> wire for the quad interface(s) IP addresses ( qeXX). Snooping
> shows the arp requests generated by other hosts are present on
> the wire but go unanswered by the routing host.
>
> Another machine supplying aproxy arp for the qe interfaces
> allows communication of other machines thru the interfaces.
> The proxy supplies the le0 IP.
>
> Manually setting up the routing works, locally on the host
> the routing works, there is just no arp response. Netmasks
> discriminate the interfaces as different class C domains,
> ie 0Xfffffc00, all under one class B domain.
>
> A look through the ndd effects has not enlightened me --
> I don't see anything applicable that is not set OK.
> The arp table shows the interfaces correctly published.
>
> I did not see anything related to arp in the faq,
> It's a nice puzzle, but I really need to get it to
> work without the proxy RSN!
>
> Thanks in advance for any brain cycles anyone can
> spare or pointing out the obvious to me!
>
> ***** Bob Hayes <bob@cs.wwu.edu> *****
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Blander =8^)
Sr. Systems Engineer Applied Computer Solutions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone: (714) 842.7800 Fax: (714) 842.8299
Email: Daniel.Blander@acsacs.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Official Applied Computer Solutions Home Page
and Tech Tip of the Week:
http://www.acsacs.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>From casper@Holland.Sun.COM Wed Feb 14 00:04 PST 1996
Return-Path: <casper@Holland.Sun.COM>
Received: from mercury.Sun.COM by reef.cs.wwu.edu (5.0/SMI-SVR4)
id AA24561; Wed, 14 Feb 1996 00:04:30 -0800
Received: from snail.Sun.COM by mercury.Sun.COM (Sun.COM)
id AAA19668; Wed, 14 Feb 1996 00:05:37 -0800
Received: from Holland.Sun.COM (isunnl) by snail.Sun.COM (4.1/SMI-4.1)
id AA15320; Wed, 14 Feb 96 00:05:34 PST
Received: from albano by Holland.Sun.COM (4.1/SMI-4.1-sd.fkk2004)
id AA03861; Wed, 14 Feb 96 09:05:15 +0100
Received: from holland (room101) by albano (5.0/SMI-SVR4-se.fkk110)
id AA19673; Wed, 14 Feb 1996 09:05:13 +0100
Message-Id: <9602140805.AA19673@albano>
To: bob@reef.cs.wwu.edu (bob hayes)
Subject: Re: No arp reply, multi interface?
In-Reply-To: Your message of "Tue, 13 Feb 1996 09:19:43 PST."
<9602131719.AA22276@reef.cs.wwu.edu>
Date: Wed, 14 Feb 1996 09:05:13 +0100
From: Casper Dik <casper@Holland.Sun.COM>
Content-Type: text
Content-Length: 969
>I have a quad ether board on an ultra/solaris 2.5 box.
>The machine is set to act as a router between le0 and qeXX's.
>
>There is no arp reply generated for arp requests on the le0
>wire for the quad interface(s) IP addresses ( qeXX). Snooping
>shows the arp requests generated by other hosts are present on
>the wire but go unanswered by the routing host.
This is the correct behaviour.
What you want is routing, not using PROXY arp.
>Another machine supplying aproxy arp for the qe interfaces
>allows communication of other machines thru the interfaces.
>The proxy supplies the le0 IP.
>
>Manually setting up the routing works, locally on the host
>the routing works, there is just no arp response. Netmasks
>discriminate the interfaces as different class C domains,
>ie 0Xfffffc00, all under one class B domain.
That's not calls see (that's 0xffffff00), but that's irrelevant.
You need to add a route on the IP clients and run routed on the Ultra.
Casper
>From wezel@bio.vu.nl Wed Feb 14 04:33 PST 1996
Return-Path: <wezel@bio.vu.nl>
Received: from bio.vu.nl ([130.37.80.1]) by reef.cs.wwu.edu (5.0/SMI-SVR4)
id AA25000; Wed, 14 Feb 1996 04:33:51 -0800
Received: from pseudorca.bio.vu.nl by bio.vu.nl (4.1/SMI-4.1)
id AA02229; Wed, 14 Feb 96 13:34:57 +0100
Date: Wed, 14 Feb 96 13:34:57 +0100
From: wezel@bio.vu.nl (Jos van Wezel)
Message-Id: <9602141234.AA02229@bio.vu.nl>
To: bob@reef.cs.wwu.edu
Subject: Re: No arp reply, multi interface?
Sender: jvw@bio.vu.nl
Content-Type: text
Content-Length: 297
Could it be you changed something with ifconfig AFTER the machine had
booted? (like resetting a broadcast address or netmask)
I had the same problem you describe on 2.5. Everything was OK after reboot.
Seems something in the enet drivers gets stuck after fiddling with ifconfig.
Jos VanWezel
>From mshon@sunrock.East.Sun.COM Wed Feb 14 07:06 PST 1996
Return-Path: <mshon@sunrock.East.Sun.COM>
Received: from mercury.Sun.COM by reef.cs.wwu.edu (5.0/SMI-SVR4)
id AA25144; Wed, 14 Feb 1996 07:05:55 -0800
Received: from East.Sun.COM by mercury.Sun.COM (Sun.COM)
id HAA10281; Wed, 14 Feb 1996 07:07:01 -0800
Received: from sunrock.East.Sun.COM by East.Sun.COM (5.x/SMI-5.3)
id AA20159; Wed, 14 Feb 1996 10:06:57 -0500
Received: from caldera.East.Sun.COM by sunrock.East.Sun.COM (5.0/SMI-5.3-900117)
id AA27437; Wed, 14 Feb 1996 10:06:55 -0500
Received: by caldera.East.Sun.COM (5.x/SMI-SVR4)
id AA23924; Wed, 14 Feb 1996 10:06:52 -0500
Date: Wed, 14 Feb 1996 10:06:52 -0500
From: mshon@sunrock.East.Sun.COM (Michael J. Shon {*Prof Services} Sun Rochester)
Message-Id: <9602141506.AA23924@caldera.East.Sun.COM>
To: bob@reef.cs.wwu.edu
Subject: Re: No arp reply, multi interface?
Cc: mshon@sunrock.East.Sun.COM
X-Sun-Charset: US-ASCII
Content-Type: text
Content-Length: 4473
Now, I may misunderstand how ARP is supposed to work,
but I think it goes this way:
|
|I have a quad ether board on an ultra/solaris 2.5 box.
|The machine is set to act as a router between le0 and qeXX's.
|
|There is no arp reply generated for arp requests on the le0
|wire for the quad interface(s) IP addresses ( qeXX). Snooping
|shows the arp requests generated by other hosts are present on
|the wire but go unanswered by the routing host.
ARP is a MAC-layer protocol independent of the higher layers,
a kind of a sneaky way to make them work. It can be used for
protocols other than IP.
ARP replies are only generated on a port when an ARP request
comes in for the IP address of that same port
(unless you set up proxy ARP).
The le port is correct to ignore ARP requests for IP addresses of
qe ports.
It's kind of a "per-wire" protocol, and only makes sense on a
given wire.
Routing is more general, and handles the problem of how to move
things between different wires. Arp requests will be made on
each wire to find the ether address for the ether ports involved
in routing to the destination .
|
|Another machine supplying aproxy arp for the qe interfaces
|allows communication of other machines thru the interfaces.
|The proxy supplies the le0 IP.
[
If you want to set up proxy arp on the Sun, you can
arp -s qe_IP le_ether pub
for each qe_IP in a new file like /etc/rc2.d/S99proxyarp .
]
|
|Manually setting up the routing works, locally on the host
|the routing works, there is just no arp response. Netmasks
|discriminate the interfaces as different class C domains,
|ie 0Xfffffc00, all under one class B domain.
Good.
The Sun is happy to forward IP packets which come in with
destination IP addresses on its other subnets,
[ if ip_forwarding is 1 or 2 ] but for them to
be seen, they have to be sent to the right ether address.
That is, on the le net, a packet for the a qe net can be routed
if it is sent to the le ether address. This can be done 2 ways:
by proxy arp (as you seem to have done), or by telling the source system
that the le IP address is the gateway to the qe IP net so that
it knows to direct the packet to the Sun router.
This could be done via explicit host routes, routing protocols,
or by setting the Sun as a default router.
These are the normal methods, any of which may not be supported
on your "client" platform(s).
The client on the le ethernet should *know* through one of these methods,
that to address a qe IP subnet it needs to talk to the le IP address
because the le IP is the appropriate router.
It ARPs the le IP address [ the router address ]
and gets the le ether address.
It send the packet with an IP address for the qe network to the
le ether address.
The le port gets the packet, sees that it is destined for another
IP subnet, and looks for a route. It finds that one of the qe ports
is on the IP subnet which the packet wants to get to [ the packet may
be for the qe IP address itself, or for someone else on the subnet].
If it is for for the qe IP itself, then it can be delivered internally.
If not, then the qe port will ARP for the destination IP on the qe wire.
Once it gets a response, the IP packet will be sent to that ether address.
Routing accomplished.
|
|A look through the ndd effects has not enlightened me --
|I don't see anything applicable that is not set OK.
|The arp table shows the interfaces correctly published.
|
|I did not see anything related to arp in the faq,
|It's a nice puzzle, but I really need to get it to
|work without the proxy RSN!
The key, then is to teach the clients that IP address
of the Sun ethernet port on the same IP subnet is the
gateway or router address.
After that, it takes care of itself.
By default, a Sun with multiple interfaces runs router discovery
protocols and broadcasts its router tables periodically.
Single-port Suns with an /etc/defaultrouters file will use the
addresses in there for routers.
Single-port Suns with an empty or missing /etc/defaultrouters file
will run routed to listen for the routing info from other routers.
see /etc/init.d/inetinit on Solaris 2 .
Michael Shon (716) 385-5065 michael.shon@East.Sun.COM
Any information or views presented here derive from my own experience,
and are definitely NOT official Sun recommendations or policies.
|
|Thanks in advance for any brain cycles anyone can
|spare or pointing out the obvious to me!
|
|***** Bob Hayes <bob@cs.wwu.edu> *****
|
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:53 CDT