Bringing External Connectivity and Experimenters to GENI Nick

Bringing External Connectivity and Experimenters to GENI Nick Feamster

Cluster • Goal: Bring external connectivity to experiments through seamless integration with experiments on virtual networks

Background: BGP Autonomous Systems Route Advertisement Traffic Session

Problem • Virtual networks need upstream connectivity – Ability to receive routes for rest of internet – Ability to advertise routes • But, experiments using virtual networks may also be transient – High overhead for setting up new sessions – Transient nature of BGP sessions may create global instability

Individual Sessions Not Scalable AS 1 AS 2 BGP Sessions Virtual AS 1 GENI, Proto. GENI, VINI Virtual AS 2

Solution: BGP Mux AS 1 AS 2 BGP-Mux Virtual AS 1 Virtual AS 2 GENI, Proto. GENI, VINI

Design Requirements • Session transparency: BGP updates should appear as they would with direct connection • Session stability: Upstreams should not see transient behavior • Isolation: Individual networks should be able to set their own policies, forward independently, etc. • Scalability: Mux should support many networks

Control-Plane Implementation: Quagga • Quagga Routing Suite – Open-source BGP daemon – Cisco like CLI support – Used by real ISPs • Salient features – Multiple BGP views – Local-AS change – Transparent updates

Configuration AS 2 BGP-View – AS 1 External IP BGP Instance BGP-Mux Server AS 1 IP 1 Virtual AS 1 IP 2 Virtual AS 2

Configuration: Quagga bgp multiple-instance ! router bgp 64512 view Verio bgp router-id 147. 28. 7. 21 network 168. 62. 16. 0/21 neighbor 147. 28. 0. 4 remote-as 3130 neighbor 147. 28. 0. 4 description PSG 0 - Verio neighbor 147. 28. 0. 4 route-map BLOCK out ! router bgp 64512 view ATT bgp router-id 147. 28. 0. 212 network 168. 62. 16. 0/21 neighbor 147. 28. 0. 1 remote-as 3130 neighbor 147. 28. 0. 1 description ATT neighbor 147. 28. 0. 1 route-map BLOCK out !

BGP Server AS 1 BGP Server BGP-View – AS 2 BGP-View – AS 1 BGP Instance BGP-Mux Server Scaling with Multiple Views AS 2 External IP

Work in Progress • VINI Deployment: Two locations – Washington – Virginia – Waiting for upstream connectivity • Test clients in Emulab network – – The number of clients Memory consumption CPU consumption Update propagation speed

Next Steps • Internet 2/Proto. GENI deployment • Upstream Connectivity – Ability to advertise prefixes (need to get prefixes from I 2 for Proto. GENI) – Data Plane Integration • Integration with Emulab/Proto. GENI

Summary • Virtual networks need upstream connectivity – Transparent to experiments – Stable, from the appearance of the upstream ISP • BGP-Mux – Easy to implement – Easy to deploy – Scales

Other Aspect of Project • Ethernet GRE Tunnels within Proto. GENI • Ability to instantiate Ethernet GRE tunnels with – Open. VZ Kernel – Trellis Kernel