1. Bringing External Connectivity and Experimenters to GENI Nick Feamster

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

3. Background: BGP Route Advertisement Autonomous Systems Session Traffic

4. 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

5. Individual Sessions Not Scalable AS1 AS2 GENI, ProtoGENI, VINI Virtual AS1 Virtual AS2 BGP Sessions

6. Solution: BGP Mux AS1 AS2 BGP-Mux GENI, ProtoGENI, VINI Virtual AS2 Virtual AS1

7. 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

8. 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

9. Configuration AS1 AS2 BGP-Mux Server BGP Instance External IP IP1 IP2 BGP-View – AS1 BGP-View – AS2 Virtual AS1 Virtual AS2

10. 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 PSG0 - 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 !

11. Scaling with Multiple Views AS1 AS2 BGP-Mux Server BGP Instance External IP BGP-View – AS1 BGP-View – AS2 BGP Server

12. 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

13. Next Steps Internet2/ProtoGENI deployment Upstream Connectivity –Ability to advertise prefixes (need to get prefixes from I2 for ProtoGENI) –Data Plane Integration Integration with Emulab/ProtoGENI

14. 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

15. Other Aspect of Project Ethernet GRE Tunnels within ProtoGENI Ability to instantiate Ethernet GRE tunnels with –OpenVZ Kernel –Trellis Kernel