180 likes | 293 Views
IU Campus GENI/Openflow Experience. Matt Davy Quilt Meeting, July 22nd 2010. Outline. Quick Overview of IU Campus Network Overview of Current Openflow Deployment Deployment Methodology Issue Encountered Next Steps (0-12 months) Regional Deployments. IU Campus Network.
E N D
IU Campus GENI/Openflow Experience • Matt Davy • Quilt Meeting, July 22nd 2010
Outline • Quick Overview of IU Campus Network • Overview of Current Openflow Deployment • Deployment Methodology • Issue Encountered • Next Steps (0-12 months) • Regional Deployments
IU Campus Network • 8 Campuses Connected with Dark Fiber • 1,500+ switches with 100,000+ switch ports • 4,000+ Wireless Access Points • 2 large data centers - 1,200+ VMs • Leverage/Edge/Trust - Nearly all infrastructure centrally managed • Federated network control important aspect of Openflow
Deployment Methodology • Initially Deploy Separate Switches for Openflow • Production VLAN + Openflow Production VLAN w/o Openflow Enabled • Enable Openflow and Move Users onto Openflow VLAN • Add Openflow Research VLAN • Wireless SSID Plumbed into Openflow Production VLAN • Users can opt-in and opt-out quickly and easily • Can deploy on 4,000+ APs quickly and with little to no risk
Issues Encountered • Early bugs in HP switch implementation • Things like slow flow setup times • Most fixed in recent code • Limitations in HP Implementation • Software switched flows - Multiple output ports, L2 only flow rules • Openflow image not built against maintenance branch • Little security on Openflow controller channel • Added ACLs upstream
Issues Encountered • No IPv6 Support in Openflow • Needed by network engineers - our initial test users • Static Ether-type (0x86DD) entry in SNAC • All IPv6 is flooded and software switched • DHCP Slowness • Occasionally 1-2 mins to get DHCP lease • Originally Openflow Problem - Resolved with Code Upgrade • Now have similar problem caused by wireless controllers
Next Steps (0-12 months) • Add Openflow Specific Monitoring to GlobalNOC Tools • Deploy Openflow SSID and Actively Recruit Users • Deploy Openflow on real production switches • Develop larger, multi-vendor Openflow lab • Develop GENI Openflow Hands-On Workshop • Research using Openflow in the WAN
Next Steps (0-12 months) • Fully Operationalize Openflow • Enable Researchers to Provision Slices on Our Infrastructure • Investigate Integration of Existing Tools with Openflow • Automatic Network Isolation (ANI) • Home-Grown NAC • Sherpa - Provision network “paths” with dedicated bandwidth
Regional Deployments • Openflow Islands Need Layer-2 Connectivity • Regional Could Just Provide Layer-2 Path from Campus to I2/NLR • Potential VLAN ID Conflicts • Why Deploy Openflow in a Regional ? • Creates More Interesting/Realistic Topologies for Researchers • Standardizes Openflow Connectivity for Members • Gain Experience with GENI/Openflow
Regional Deployments • What is Needed for a Regional Deployment ? • At Least 1 Openflow Capable Switch • At Least 1 Server - Preferably with Xen/VMware • For Running Flowvisor, NOX, etc • Layer-1 or Layer-2 Connectivity • Campus to Regional Openflow Switch(es) • Internet2/NLR to Regional Openflow Switch(es)
Dedicated vs Best-Effort • Experiments Must Be Repeatable ! • Best-Effort May Be Sufficient as Initial Deployment (Overlay) • Plan to Transition to Dedicate Layer-1 Links Where Feasible • Plan for Dedicated Bandwidth on Shared Layer-2 Links in the Future