Bringing External Connectivity and Experimenters to GENI Nick Feamster

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

Route Advertisement

Autonomous Systems

Session

Traffic

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

AS1 AS2

GENI, ProtoGENI, VINIGENI, ProtoGENI, VINI

Virtual AS1

Virtual AS2

BGP Sessions

Solution: BGP Mux

AS1 AS2

BGP-Mux

GENI, ProtoGENI, VINIGENI, ProtoGENI, VINI

Virtual AS2

Virtual AS1

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

AS1AS1 AS2AS2

External IPExternal IP

IP1IP1 IP2IP2

Virtual AS1

Virtual AS2

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!

Scaling with Multiple Views

AS1AS1 AS2AS2

External IPExternal 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

• Internet2/ProtoGENI deployment

• Upstream Connectivity– Ability to advertise prefixes

(need to get prefixes from I2 for ProtoGENI)– Data Plane Integration

• Integration with Emulab/ProtoGENI

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 ProtoGENI• Ability to instantiate Ethernet GRE tunnels with

– OpenVZ Kernel– Trellis Kernel