1 / 15

Bringing External Connectivity and Experimenters to GENI

Bringing External Connectivity and Experimenters to GENI. Nick Feamster. Cluster. Goal: Bring external connectivity to experiments through seamless integration with experiments on virtual networks. Session. Background: BGP. Autonomous Systems. Route Advertisement. Traffic. Problem.

yvon
Download Presentation

Bringing External Connectivity and Experimenters to GENI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Session Background: BGP Autonomous Systems Route Advertisement 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 BGP Sessions GENI, ProtoGENI, VINI Virtual AS1 Virtual AS2

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

  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 AS2 AS1 External IP BGP-Mux Server BGP Instance BGP-View – AS1 BGP-View – AS2 IP1 IP2 Virtual AS2 Virtual AS1

  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 External IP BGP-Mux Server BGP Server BGP Server BGP Instance BGP-View – AS1 BGP-View – AS2

  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

More Related