<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: general info needed for 2.4.x
From: ewheeler,AT,kaico,DOT,com
Date: Tue, 12 Jun 2001 08:28:23 +0200
In-reply-to: <3B246242.D6F3C5DB@farmexim.ro>

Dragos --

I've had great success w/ cipe for SMB usage.  Let me help by telling you
what I learned by my mistakes and what I did to make it work:

First, I must say that I'm using 2.4.4, but I know that 2.4.5 works fine
'cause I have tested it in a different environment.  The basic procedure
is the same.

Background:
  One of our clients has a central office in portland oregon, one in
yakima washington, one in redmond washington and one in medford
oregon.  The portland office houses their database, and central
backup.  The entire system as far as workstations are concerned is windows
2000. It doesn't really matter what you use, the principle is the same; we
do have a w98 system working the same way.

First:
        Setup the cipe link between each site.  Make sure that you can
ping appropriately.  You may want to read the advanced-routing howto.  

Let's assume the following:
ifconfig for our setup on the cipe devices looks something like this (with
the useless info strpped out).  

(Portland to Medford)
cipcb0    Link encap:IPIP Tunnel  HWaddr
          inet addr:192.168.1.1  P-t-P:192.168.12.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1442  Metric:1

(Portland to Redmond)
cipcb1    Link encap:IPIP Tunnel  HWaddr
          inet addr:192.168.1.1  P-t-P:192.168.10.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1442  Metric:1

(Portland to Yakima)
cipcb2    Link encap:IPIP Tunnel  HWaddr
          inet addr:192.168.1.1  P-t-P:192.168.11.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1442  Metric:1

Second: 
The only thing missing is the route table in order to make these guys
talk.  For this example let's leave IP masquerading/SNAT out of it; that
makes things complicated.

This is portland's route table:

192.168.11.1    0.0.0.0         255.255.255.255 UH    cipcb2
255.255.255.255 0.0.0.0         255.255.255.255 UH    eth0
192.168.10.1    0.0.0.0         255.255.255.255 UH    cipcb1
192.168.12.1    0.0.0.0         255.255.255.255 UH    cipcb0
192.168.1.0     0.0.0.0         255.255.255.0   U     eth0
192.168.12.0    192.168.12.1    255.255.255.0   UG    cipcb0
1.2.3.4         0.0.0.0         255.255.255.0   U     eth1
192.168.11.0    192.168.11.1    255.255.255.0   UG    cipcb2
192.168.10.0    192.168.10.1    255.255.255.0   UG    cipcb1
0.0.0.0         1.2.3.1         0.0.0.0         UG    eth1

Useless info has been stripped, and real internet ip's have been changed
to protect the host.

notice the route to:
192.168.10.0 via 192.168.10.1
192.168.11.0 via 192.168.11.1
and 192.168.12.0 via 192.168.12.1

Similarly, there is a route on each afiliate location into the portland
system accross the cipe link.  

Medford's route table looks something like this:
192.168.1.1     0.0.0.0         255.255.255.255 UH    cipcb0
255.255.255.255 0.0.0.0         255.255.255.255 UH    eth0
4.3.2.2         0.0.0.0         255.255.255.192 U     eth1
192.168.1.0     192.168.1.1     255.255.255.0   UG    cipcb0
192.168.12.0    0.0.0.0         255.255.255.0   U     eth0
0.0.0.0         4.3.2.1         0.0.0.0         UG    eth1
Same rules apply here.

Notice that there is a route to 192.168.1.0 via 192.168.1.1.

This is a good healthy route setup.  Everyone in portland can connect (or
ping for our purposes) to any of the affiliate systems and all of the
affliliate systems can connect to portland.  Note that there is no route
for say 192.168.12.0 from yakima through portland.  If you wanted yakima
(192.168.11.0) to talk to medford, you can either create a cipe from
medford to yakima directly (fastest but requires more setup) or simply add
a route to medford through portland from medford:

on the yakima system:
route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.1.1

similarly on the medford system: 
route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.1.1

Since portland is our hub, now medford and yakima and portland can all
talk to eachother.  We didn't setup the ability for the affiliates to talk
to eachother for security purposes; they only need access to portland, but
portland needs to administrate the 3 affiliates so it can get to all of
them.

Now, for SMB browse list.

You will probably find that after setting up your locations, our
routes are solid, and everyone can ping everyone else, that the systems
seen in the browse list are only those systems for that location.  

for example: in medford, we see the systems
Jim
Bonnie
Ralf

and in Portland we see:
Fred
Carol
Wendy

Idealy, we want yakima and portland to get to eachother systems so we need
the browse list to actually contain:
Jim
Bonnie
Ralf
Fred
Carol
Wendy

For this, we need something called WINS: Windows Internet Name Service.
(note that if you've launched a completely windows 2k DNS based network
you don't need wins; w2k DNS based networks I have no experience with, so
I'll explain WINS)

First, we have to setup each work station to be a peer-peer wins system
only.  By default, windows uses TCP/IP broadcasts to make name
resolutions.  the WINS system will make it so there is a central server
queried and thus gives the ability for systems to talk across a routed
network.  I haven't found a way to make microsoft os's force peer-peer
without a dhcp server handlinging it to force peer-peer wins.  My
dhcpd.conf (using isc.org's dhcp daemon) looks something like this:
default-lease-time 600;
max-lease-time 7200;

option routers 192.168.12.1;
option domain-name-servers 192.168.12.1;
option domain-name "somewhere.com";

option netbios-name-servers 192.168.1.200;
option netbios-node-type 2;

subnet 192.168.12.0 netmask 255.255.255.0 {
        range 192.168.12.50 192.168.12.100;
}

subnet 2.3.4.64 netmask 255.255.255.192 {
}

The 'option netbios-node-type 2' line is the gravy.  This makes every
system who has been dhcp'd an address peer-peer wins which means no more
netbios brodcast traffic (makes hubs happy)!  Notice that our WINS server
is 192.168.1.200.  Unfortunately, (at least as of version 2.0.3) samba
does not work well as a WINS server when it is supposed to annouce a
specific domain (our domain will be SFD).  So when a client tries to make
a domain authentication on the SFD domain, samba says 'huh?'.  Since I
couldn't make samba work as a WINS server for this setup I used NT4's WINS
service.  Note that if you don't need domain authentication, you can use
samba as a wins server, just set 'wins support = yes' in the smb.conf
file.  It works great for everything except domain auth.  You might find
different, so if you do please let me know.

I think that's it... 

Recap:
1. Setup cipe, make all the routers ping the p-t-p link and make sure the
cipe links work.
2. Setup your routes.  It's up to you who gets access to what.  I suggest
you talk to the people in question to find out their needs (unless it's
for yourself, then do whatever).  Make sure veryone can ping everyone
else.
3. Setup DHCP.  The above example should be a good skeleton to start from.
4. setup WINS.  Make sure everyone is using the same wins server.  
5. Happy SMB exchange!

Hope this helps.  If you get any other questions, please let me know.

--Eric

On Mon, 11 Jun 2001, Dragos Delcea wrote:

> hello cipe users,
> 
> I'm investigating the posibility of using cipe 
> to create a vpn for our network (and route smb 
> traffic through it).
> Both of the connection ends would be linux with 
> 2.4.5 or higher kernel
> 
> questions:
> is cipe working with kernel 2.4.5 or higher?
> what version of cipe is needed for that (if
> it works at all)?
> where do I find some (good) documentation 
> about it?
> 
> 
> Regards
> 
> Dragos
> Bucharest, Romania
> 
> 
> --
> Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive: 
><URL:http://sites.inka.de/~bigred/devel/cipe.html>
> 





<< | Thread Index | >> ]    [ << | Date Index | >> ]