Page Comparison

 

This week UIT Network Engineering successfully piloted the migration of DHCP service for wired users in the Tufts Administration Building. IP addresses are now being assigned by the BlueCat servers and unregistered hosts are being registered through the new BlueCat captive portal system.

BlueCat makes use of a new web site to provide simple registration of hosts when you have the MAC address but are not at the system, or don't want to enter your credentials into the user's system via TUNIS. This new site is available now at the following address:

  https://hostreg.net.tufts.edu

UIT has begun working with the various IT support organizations to select an additional subnet on each campus to pilot DHCP migration. Once these additional subnets are successfully migrated onto the BlueCat platform and this collaborative pilot complete, UIT will work to migrate the rest of university's networks to the new DHCP servers by the end of July. A more detailed schedule for these migrations will be distributed shortly.

On the day a network is migrated users may notice some minor interruptions. The most frequent issue will be for users who registered new devices on the network after February 23rd. These users will be prompted to re-register their devices on the BlueCat captive portal. While the back-end of the portal has been replaced, the end-user experience is nearly identical to the TUNIS web interface that they may have seen in the past. Host expiration has been suspended since February 23rd, so the only devices that should be impacted are those that are new to the network.

While TUNIS and the proxy registration page have largely remained the same on BlueCat, FSPs will notice a few changes:

* Registrations will now take effect immediately on the DHCP servers. Without intervention there will still be some delay while waiting for the DHCP lease to renew, but if you run an ipconfig /release, /renew or similar, the host will immediately receive a valid IP address.

* There is a new required field on the proxy page, "registered for." The UTLN of the system owner should be entered in this field. If the user does not have a UTLN, you must enter your own UTLN.

* On the proxy registration screen the expiration date still defaults to one year or 7 years depending on the device class you select (tufts-user or tufts-asset), but if you need to select a shorter duration the expiration field now provides a quick drop-down to select an appropriate duration rather than manually entering a specific number of days.

* Users will still be directed to the TUNIS screen automatically when they open a web browser on an un-registered system, however the TUNIS page has a different IP address and name (portal.net.tufts.edu).

When a subnet is migrated users will automatically begin receiving the new recursive DNS

 resolvers
{indent}  http://www.net.tufts.edu/nameserver.html

    130.64.25.5    ns.medford.tufts.edu

    130.64.35.5    ns.boston.tufts.edu

    130.64.249.5   ns.grafton.tufts.edu

{indent} 

Unlike the old system, which utilized different DNS server IP addresses for registration and restricted users, these same IP addresses will be provided to all users regardless of their registration status.

*IMPORTANT CAVEATS:

*
* If your organization manages any firewalls that restrict outbound traffic they will need to be configured to permit traffic to the new DNS servers noted above.

* On the day a subnet is migrated firewalls that forward DHCP traffic to our servers will need to change their ip helper-address to the new DHCP server for their campus. UIT Network Engineering will coordinate these changes for all UIT managed firewalls. If you manage a firewall that may be impacted by this change please contact us so we can coordinate the changes with minimal interruption to your users.

* Users may experience transient IP address conflicts. These can usually be fixed by waiting, running an ipconfig /release; ipconfig /renew, or rebooting.

** The new DHCP server will have no knowledge of which dynamic addresses are in use. It will send an icmp ping packet before assigning any IP, but if a system is sleeping or has a personal firewall enabled the DHCP server will still assign that IP. To help mitigate this issue we plan to shorten the lease time on the old servers prior to the migration. This will cause active clients to notify the new DHCP server of the IP address they are using more quickly after the migration, lowering the period where a new host on the network may accidentally be assigned an IP already in use.

* Users with dynamic addresses are more likely to have their IP address change.

** In some underutilized subnets systems with dynamic addresses almost always receive the same IP address. The new DHCP server will have no knowledge of this prior assignment so users with dynamic IPs may experience a change in their IP address.

* If a DHCP reservation or other setting was configured after February 23rd in Cardinal but not in BlueCat the system will revert to its status prior to February 23rd after the migration.

* If a DHCP reservation or other setting was configured after February 23rd in BlueCat but not Cardinal the change will take effect after the migration.