Visionfs over a Cisco 1600 router
Mark Comins
I am using a Cisco 1600 router over a 56K leased line to connect a remote
office to a SCO Rel5 Enterprise
system. We are using Win95 systems with Termlite to connect to the SCO box.
The local users also have use of the Visionfs services for file sharing and
print services. I am trying to get the remote site to see the Visionfs
shares on the filesystem. I know on samba we need to edit the smb.conf to
allow the other network access to you due to the different subnet address.
I believe you also need to edit nmdb in Samba to announce the server's
availability to the NetBios clients.
I am running Visionfs ver 1.20.907. Any suggestions would be appreciated.
thanks,
Mark Comins
Matt Schofield
>
> Greetings,
>
> ... I am trying to get the remote site to see the Visionfs
> shares on the filesystem.
The router software will probably by default block broadcast packets, so
Windows workgroups/Network Neighbourhood won't span the router. You
won't to be able to browse for the server via Network Neighbourhood ,
but you should be able to connect and map drives to it by doing the
following:
1. If you use a WINS server, add VisionFS as a static mapping, else add
an entry to one of the PC's \windows\lmhosts file. See
\windows\lmhosts.sam for more info.
2. Go to the Start -> Run... menu and type \\<servername>.
What this does is tell the SMB client the IP address of the SMB server.
The appropriate routed connection can then be made over the router.
This should give you the list of shares as if you had double clicked
<server> in network neigbourhood. These shares can then be configured to
be remapped to drive letters at Windows logon.
Regards
Matt Schofield
--
Return email address junked.
Bill Vermillion
Matt Schofield <mat...@sco.deletethisbit.com> wrote:
>Mark Comins wrote:
>>
>> Greetings,
>>
>> ... I am trying to get the remote site to see the Visionfs
>> shares on the filesystem.
>The router software will probably by default block broadcast
^^^^^^ ^^^^^^^^^^
>packets, so Windows workgroups/Network Neighbourhood won't span the
>router.
True.
I'm not familiar with the 1600. However routers descended from
bridges. He probably needs to bridge the network, and then all
should be well. A bridge will span the entire network. If it can not
find the address on it's own segment it goes to the bridge which
then issues a broadcast to all connected there. Not as efficient as
routing but unless its a very heavily used network it shouldn't make
a lot of difference.
Bridges - CON
Based on the topology - not on best path as in a router
Reconfiguration after change takes longer
Total number of stations bridged is "limited to the tens of
thousands".
Bridges offer no firewall protection.
Bridges drop packets that are too large to forward
Bridges can't give congestion feedback.
Bridgs - PRO
Bridges really are plug and play.
Bridges have better price/performance than routers
Bridges are multiprotocol
Bridges forward even nonrouting protolcs.
That's pretty much verbatim Radia Perlman's book
"Interconnections". Good book.
--
Bill Vermillion bv @ wjv.com
StormCrow
bi...@bilver.magicnet.netREMOVETHIS says...
>
>I'm not familiar with the 1600. However routers descended from
>bridges. He probably needs to bridge the network, and then all
>should be well. A bridge will span the entire network. If it can not
>find the address on it's own segment it goes to the bridge which
>then issues a broadcast to all connected there. Not as efficient as
>routing but unless its a very heavily used network it shouldn't make
>a lot of difference.
>
>Bridges - CON
>Based on the topology - not on best path as in a router
>Reconfiguration after change takes longer
>Total number of stations bridged is "limited to the tens of
> thousands".
>Bridges offer no firewall protection.
>Bridges drop packets that are too large to forward
>Bridges can't give congestion feedback.
>
>Bridgs - PRO
>Bridges really are plug and play.
>Bridges have better price/performance than routers
>Bridges are multiprotocol
>Bridges forward even nonrouting protolcs.
>
>That's pretty much verbatim Radia Perlman's book
>"Interconnections". Good book.
>
>
>--
>Bill Vermillion bv @ wjv.com
He almost certainly does NOT want to bridge. Since he only has a 56k line,
bridging would allow for a whole lot of traffic over that line that he
probably doesn't need.
He probably has two problems, one is that his remote clients can't resolve
the host name (doesn't have a lmhost entry or a configured WINS server or IOS
setup to forward UDP name broadcasts) and the other is that he may not have a
route set up from the SCO box back to the clients in the other subnet. If he
already has telnet connectivity then the two boxes can talk to each other..
Now let's talk netbios name resolution.
There are a few ways to do this.. Assuming a pure TCP/IP network (no NetBEUI
or IPX) then you have three choices:
1) Bridging. Like Bill said, this will get the job done, at the expense of
some bandwidth overhead. There is no technical reason to need to do this if
you are running pure TCP/IP though. On a properly configured network you
simply don't need to do it. Bridging is the older (or wuick and dirty) way
to go. Routing keeps your network bandwidth optimized.
2) WINS server on the CLIENT side of the network. LMHOSTS file can do this
too.. Easy way to go (LMHOSTS) if you have a small number of clients.
3) enable the "ip helper-address" command on your routers.. This will forward
the WINS packets from your WINS server on the "other" side of your network to
the remote side. It would go "ip helper-address _wins-server-address_" where
_wins-server-address_ is the IP address of your WINS server.
My reccomendation is to use the last one.. Keeps the admin down to a minimum.
If you have IPX as well, you may also need: ipx type-20-propogation to be
enabled.
Hope this helps you.
Matt Schofield
> 2) WINS server on the CLIENT side of the network. LMHOSTS file can do this
> too.. Easy way to go (LMHOSTS) if you have a small number of clients.
Can't a WINS server be anywhere because it's specified via an IP
Address? Assuming no firewalls and correctly defined routes, a WINS
client should be able to query the server from over a router.
Or are you just saying it may be advantageous to have it on the client
side?
Correct me if I'm wrong.
Bill Vermillion
StormCrow <storm...@technologist.com> wrote:
>In article <F77EJ...@bilver.magicnet.netREMOVETHIS>,
>bi...@bilver.magicnet.netREMOVETHIS says...
Re My comment on briding.
>>Not as efficient as routing but unless its a very heavily used
>>network it shouldn't make a lot of difference.
>He almost certainly does NOT want to bridge. Since he only has a
>56k line, bridging would allow for a whole lot of traffic over
>that line that he probably doesn't need.
The problem in the original post was that the only thing specified
was 56K and not much of a clue except using Termlite and VisionFS.
Bandwidth is dependant on the application and the useage.
Given the data in the original post it's hard to say what bandwidth
is required. I have a site that moved their office staff across
town and are on 56K line. This is routed. However there are over
a dozen Wyse60s, a 1/2 dozen or more PC's, and a couple of
high-speed printers that occasionaly start printing two
or three hour runs.
Speed is amazingly fast. But most of the data being transported is
pure character based, and all the printouts are pure ascii with no
printer controls used anywhere.
>He probably has two problems, ....
If there are only two he's lucky.
Bill
StormCrow
mat...@sco.deletethisbit.com says...
The WINS server CAN be anywhere, but you have to have the router set up to
allow it (the WINS server) to advertise, that is what the IP HELPER ADDRESS
command is for.. WINS is definately the way to go as far as reduced admin is
concerned. Especially since you can now sorta roll DNS & WINS together.
StormCrow
bi...@bilver.magicnet.netREMOVETHIS says...
Yeah, you can squeeze a lot out of a 56k line.. I even have Exchange doing
site connection over them (even though MS insists it will only work with
128k+).
My only other comment is that if you are able to, routing is preferable to
bridging.. Every little bit of bandwidth saving helps IMHO!
--] SC
Kevin Smith
On of my customers has a very similar setup using cisco 1000 routers.
At the remote end I used the command
int e0
ip helper-address ip-of-visionfs-server
e0 was the ethernet interface (not the 56k (s0)).
This enables udp broadcast forwarding. I needed to use bootp
initialization of some print servers. I don't remember how it
affected the network neighborhood. Sometimes I just had to
do a "find computer" and create a shortcut in the network
neighborhood... Of course, if find can find it, broadcasts
must be working??? I also noticed that "find computer" would
work but nothing would ever pop up in the neighborhood by itself
unless file sharing was enabled in the network config (even if you
weren't planning to export anything).
Also in order to get rip routing (probably should have just stuck
with static but...), on each router
router rip
neighbor ip-of-other-router-serial-interface
--
Do two rights make | Kevin Smith, ShadeTree Software, Philadelpha, PA, USA
a libertarian | 001-215-487-3811 shady.com,kevin bbs.cpcn.com,sysop