Re: [Netpass-users] Network Arch Opinions/Questions

[Jeff M. <jcm...@os...>]

On Fri, 2005-06-17 at 15:17 -0400, Don Rugh wrote:
> Looking for some opinions on exactly how to roll NetPass out:
> 
> 
> Present Configuration
> - Each of 5 residence halls is on its own subnet and VLAN
> - Switch closets in each RH collapse back into a L3 aggregation switch
> before traveling back to the core via 1GB fiber
> 
> 
> Possible Configurations
> - Each building has its own NetPass/DNS/DHCP servers, so QVLAN never
> leaves the building
> - Could "lose" a building if a single unit fails
> vs.
> - 2 HA campus-wide servers
> - would have to tag QVLAN back thru core to allow DNS/DHCP access ==>
> or are these supposed to be routed thru the NP server(s)??

we do that latter. in either case you really only need your central
DNS/DHCP servers. you dont need, even in the former case, separate
dhcp/dns servers per-building.

> 
> 
> Still a little fuzzy on exactly how to roll this out...any help/advice
> would be appreciated.
> 

here's a typical scenario:

1) client offline, port is quarantined
2) client boots
3) sends out dhcpdiscover
4) netpass relays the dhcp pkt to your central server 
	(/etc/sysconfig/dhrelay [1])
5) central server replies to pkt src addr (hopefully [2])
6) dhcp transaction proceeds thru various stages
7) client acquires address
8) client opens web browser, goes to www.msn.com
9) netpass server intercepts (iptables)
10) redirects to squid
11) squid consults url list
12) www.msn.com not on approved list
13) squid sends http redirect to client sending them to
netpass.whatever.edu
14) clients requests that page
15) since that page is on the local server, iptables doesnt redirect
to squid, allows connect to local machine
16) apache picks it up
17) scan,reg happens
18) netpass moves client port to 'unquar' vlan
19) clients traffic flows thru 'normal' network path (not thru
    netpass server)

so, assuming you want to netpass enabled port 1 on [edge sw]:

[edge sw]----[bldg sw]----[core l3]

to implement it per-building, you would:

1) configure [edge sw] so that both vlans (e.g. 100 and 200, 
unquar and quar respectively) are available
2) configure [bldg sw] likewise. 
3) configure the uplink from edge to bldg as a trunk/tagged port and add
both vlans to it. 
4) configure edge port 1 into vlan 200 (initial state)
5) hang netpass server off of one of the ports on bldg sw and
configure /that/ port as a trunked port with both vlans on it.
6) configure the uplink from bldg to core with just vlan 100.

at this point, vlan 100 (unq) has a path from the edge port to the core.
if port 1 is in vlan 100, plugging in a client should work as normal. if
the port is moved to vlan 200 (manually), then there is no path out of
the building. the netpass server is lurking on that vlan. 

7) configure netpass and start "garp" (/etc/init.d/garpctl start)

at this point, the netpass server starts emitting ARP packets so that
clients in the quar vlan will see it as the new gateway (same IP as the
gateway on [core] but with a new mac address. with cisco 65xx, you dont
need to do this, but in other environments, GARPs are needed.

8) configure dhrelay and restart that service[1]
9) plug in the client

at this point client should get an address. if it does not, your DHCP
server is probably experiencing the problem discussed below[2]

10) open web browser, client should see netpass welcome. 


for a central deployment, you'd trunk the two vlans back to a single
location and probably use HA to ensure availability and scalability.


jeff



[1] i think this is not documented, or poorly. dhcrelay looks something
like:

# Command line options here
INTERFACES="eth0 eth1.812 eth1.813"
DHCPSERVERS="128.205.1.32 128.205.1.33"

    you probably have to do that by hand and restart that service. the 
    install script and/or web UI doesnt configure it for you.

[2] http://marc.theaimsgroup.com/?l=dhcp-server&m=108558416803846&w=2
    ISC DHCP, out of the box, replies the giaddr and not the pkt source
    addr, so the reply gets routed away from the netpass server and 
    the client cant get an address. a patch has been submitted to ISC
    for inclusion into a future release of DHCPD. the patch is posted
    to SF. YMMV with other DHCP servers.