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

[Don R. <don...@em...>]

This is a great explanation of how all the parts & pieces work  
together -- would be nice to have this find its way at some point  
into the documentation for the project!

I think we're leaning towards central servers, so the two VLANs from  
each building would be directed back to the core, and the core ports  
for the NP servers would be tagged with _all_ the VLANs, 10 in this  
case. Things get a little fuzzy here -- those 10 VLANs would then  
also have to be defined on each server, so that they could be members  
of each VLAN, correct? (since there is only _one_ default VLAN on the  
core port for untagged traffic) Or am I making this more complicated  
than it needs to be?

Thanks,
Don

Donald G. Rugh
Director of Network Services
Information Services
Saint Vincent College
300 Fraser Purchase Road
Latrobe, PA 15650
724-805-2559
don...@em...

On Jun 17, 2005, at 3:59 PM, Jeff Murphy wrote:

> 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.
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Netpass-users mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netpass-users
>