1 / 12

Bringing External Connectivity and Experimenters to GENI

Bringing External Connectivity and Experimenters to GENI. Nick Feamster Georgia Tech. Session. Networks Use BGP to Interconnect. Autonomous Systems. Route Advertisement. Traffic. Virtual Networks Need BGP, Too. Strawman Default routes Public IP address Problems

berit
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 FeamsterGeorgia Tech

  2. Session Networks Use BGP to Interconnect Autonomous Systems Route Advertisement Traffic

  3. Virtual Networks Need BGP, Too • Strawman • Default routes • Public IP address • Problems • Experiments may needto see all upstream routes • Experiments may needmore control overtraffic • Need “BGP” • Setting up individualsessions is cumbersome • …particularly for transient experiments ISP 2 ISP 1 BGP Sessions GENI

  4. Solution: BGP Mux • Separate BGP view for each upstream ISP • Private AS numbersare removed beforepropagation • “local-as” function for client connections • Small advertisement interval • Unchanged BGP attributes BGP Mux

  5. Quagga Configuration: Client Side 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 Sprint 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 Sprint neighbor 147.28.0.1 route-map BLOCK out !

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

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

  8. AS1 AS2 External IP BGP-Mux Server BGP Server BGP Server BGP Instance BGP-View – AS1 BGP-View – AS2 Scaling • Problems • Forwarding table size • Forwarding speeds • Possible Solutions • Split views across nodes • Hardware-accelerated forwarding (NetFPGA, OpenFlow)

  9. Current Status • Prefix 168.62.16.0/21 via two locations • Georgia Tech (AS 2637) • PSGNet (AS 3130) • BGP routing sessions into OpenVZ containers • ProtoGENI-compatible • Current steps • Transition to public AS number and “swip” • VINI integration, Aggregate manager • Deployments: Wisconsin, Utah, Princeton, KDDI • Applications: with Jennifer Rexford and Aki Nakao

  10. Whence Measurement? • Measuring the Internet with BGP Mux • “Real-time RouteViews” (also, local views) • Subsumes “Beacon” work • Opportunity to measure how system would interact with today’s Internet • Today’s network and routing infrastructure • Opportunity to attract real user traffic

  11. Summary • Virtual networks need upstream connectivity • Transparent to experiments • Stable, from the appearance of the upstream ISP • Solution: BGP-Mux • Easy to implement (Quagga config + Tunnelling) • Easy to deploy (please help!) • /30 prefix • VLAN between Mux and border router • Ability to advertise BGP route

More Related