tutorial: bringing experimenters to geni with the transit portal vytautas valancius, hyojoon kim,...
Post on 11-Jan-2016
216 Views
Preview:
TRANSCRIPT
Tutorial: Bringing Experimenters to GENI with the Transit Portal
Vytautas Valancius, Hyojoon Kim, Nick FeamsterGeorgia Tech
2
Agenda
• Motivation: Custom routing for each experiment• Demonstration• How you can connect to Transit Portal• Experiment Ideas
– Anycast– Service Migration– Flexible Peering
• Using Transit Portal in Education– Example problem set
• Summary and Breakout Ideas
3
Networks Use BGP to Interconnect
Route Advertisement
Autonomous Systems
Session
Traffic
4
Virtual Networks Need BGP Too
• Strawman– Default routes– Public IP address
• Problems– Experiments may need
to see all upstream routes– Experiments may need
more control overtraffic
• Need “BGP”– Setting up individual
sessions is cumbersome– …particularly for transient
experiments
ISP 1 ISP 2
BGP Sessions
GENI
5
• Obtain connectivity to upstream ISPs– Physical connectivity– Contracts and routing sessions
• Obtain the Internet numbered resources from authorities
• Expensive and time-consuming!
Route Control Without Transit Portal
6
Route Control with Transit Portal
Experiment Facility
Experiment Facility
Experiment 1
Experiment 2
Internet
Internet
ISP1ISP1
ISP2ISP2
Virtual Router
B
Virtual Router
B
Virtual Router
A
Virtual Router
A
Transit PortalTransit Portal
Routes
Packets
Full Internet route control to hosted cloud services!
7
Connecting to the Transit Portal
• Separate Internet router for each service– Virtual or physical routers
• Links between service router and TP– Each link emulates connection to upstream ISP
• Routing sessions to upstream ISPs– TP exposes standard BGP route control interface
8
Transit PortalTransit Portal
Virtual BGP
Router
Virtual BGP
Router
Basic Internet Routing with TP
• Experiment with two upstream ISPs
• Experiment can re-route traffic over one ISP or the other, independently of other experiments
ISP 1ISP 1 ISP 2ISP 2
Interactive Cloud Service
BGPSessions
Traffic
9
Current TP Deployment
• Server with custom routing software– 4GB RAM, 2x2.66GHz Xeon cores
• Three active sites with upstream ISPs– Atlanta, Madison, and Princeton
• A number of active experiments– BGP poisoning (University of Washington)– IP Anycast (Princeton University)– Advanced Networking class (Georgia Tech)
10
Demonstration of Transit Portal
11
Demonstration Setup
TransitPortalTransitPortal
GT(AS 2637)
GT(AS 2637)
VPNTunneling Virtual
RouterVirtualRouter
: BGP connectivity
Client network:168.62.21.0/24
Private AS
65002
Private AS
65002
Public AS
47065
Public AS
47065
Looking-glass Server
Looking-glass Server
Traceroute
route-server.ip.att.net
12
1. Pick a device which will be the virtual router (Linux)
2. Request for needed resources & provide information
For tunneling: CA certificate, client certificate & key
Get prefixes that the client will announce
3. Make tunneling connection with Transit Portal
4. Set up BGP daemon in virtual router (e.g. Quagga)
5. Make proper changes to routing table if necessary
6. Check BGP announcements & connectivity (BGP table)... and you
are good to go!
How You Can Connect to Transit Portal
13
Steps for Connecting to Transit Portal
• Setting up virtual machines
• Tunneling to the TP: Installing OpenVPN• Getting routes: Setting up BGP• Forwarding traffic: Setting up the data plane• Testing connectivity: Traceroute
14
Tunneling to the Transit Portal
• Install OpenVPN Client• Set up OpenVPN Connectivity (currently manual)
– Get key pair from Transit Portal operator(Valas Valancius)
– Determine IP address of tunnel endpoint– Notify operator of tunnel endpoint IP address
• Test connectivity (e.g., ping TP tunnel endpoint)
15
Sample OpenVPN Configuration
# OpenVPN config file
client
dev tunproto tcpremote 143.215.254.26 6000nobind
persist-keypersist-tun
# certification partca ca.crtcert nick.crtkey nick.key
16
Discovering Internet Routes
• Install Quagga software router• Download configuration template from GENI wiki• Modify template with tunnel endpoint IP addresses• Run bgpd and zebrad• Check Linux kernel routing tables for routes
• Advertising routes: Need IP prefix (we have some)
17
Example Quagga Configuration
!hostname kendallpassword XXXXX!router bgp 65003 bgp router-id 168.62.21.15 network 168.62.20.0/24 neighbor 168.62.21.1 remote-as 2637!access-list vty permit 127.0.0.1/32!line vty access-class vty!
hostname kendallpassword crazymuxaccess-list vty permit 127.0.0.1/32!
bgpd configuration zebra configuration
18
Setting Up Traffic Forwarding
• Give some machine in your testbed an address within the IP prefix
• Configure “gateway” to route traffic for that IP address to the appropriate location
19
Experiments Using Transit Portal
20
Experiment 1: IP Anycast
• Internet services require fast name resolution
• IP anycast for name resolution– DNS servers with the same IP address– IP address announced to ISPs in multiple locations– Internet routing converges to the closest server
• Available only to large organizations
21
ISP1
ISP1
ISP2
ISP2
ISP3
ISP3
ISP4
ISP4
Transit PortalTransit Portal
Transit PortalTransit Portal
Asia North America
Anycast Routes
Name ServiceName Service
IP Anycast
• Host service at multiple locations (e.g., on ProtoGENI)• Direct traffic to one instance of the service or another using anycast
22
Using TP in Courses
23
• Used in “Next-Generation Internet” Course at Georgia Tech in Spring 2010
• Students set up virtual networks and connect directly to TP via OpenVPN (similar to demonstration)– Live feed of BGP routes– Routable IP addresses for in class topology inference
and performance measurements
Using TP in Your Courses
24
Example Problem Set
• Set up virtual network with– Intradomain routing– Hosted services– Rate limiting
• Connect to Internet with Transit Portal
25
More Example Experiments
26
• Internet services in geographically diverse data centers
• Operators migrate Internet user’s connections
• Two conventional methods:– DNS name re-mapping
• Slow– Virtual machine migration with local re-routing
• Requires globally routed network
Experiment 2: Service Migration
27
ISP1
ISP1
ISP2
ISP2
ISP3
ISP3
ISP4
ISP4
Transit PortalTransit Portal
Transit PortalTransit Portal
Asia North America
Tunneled SessionsTunneled Sessions
Active GameService
InternetInternet
Service Migration
28
Experiment 3: Flexible Peering
Hosted service can quickly provision services in the cloud when demand fluctuates.
29
Ongoing Developments
• More deployment sites– Your help is desperately needed
• Integrating TP with network research testbeds (e.g., GENI, CoreLab)
• Faster forwarding (NetFPGA, OpenFlow)
• Lightweight interface to route control
30
Conclusion• Limited routing control for hosted services
• Transit Portal gives wide-area route control– Advanced applications with many TPs
• Open-source implementation– Scales to hundreds of client sessions
• The deployment is real– Can be used today for research and education– More information http://valas.gtnoise.net/tp
31
32
Transit Portal in the News
33
Breakout Session Agenda
• Q & A• Demonstration Redux• Brainstorming Experiments
– MeasuRouting: Routing-Assisted Traffic Monitoring– Pathlet Routing and Adaptive Multipath Algorithms – Aster*x: Load-Balancing Web Traffic over Wide-Area
Networks – Migrating Enterprises to Cloud-based Architectures
34
Extra Slides
35
Scaling the Transit Portal
• Scale to dozens of sessions to ISPs and hundreds of sessions to hosted services
• At the same time:– Present each client with sessions that have an
appearance of direct connectivity to an ISP
– Prevented clients from abusing Internet routing protocols
36
Conventional BGP Routing
• Conventional BGP router:– Receives routing updates from peers– Propagates routing update about one
path only– Selects one path to forward packets
• Scalable but not transparent or flexible
ISP1ISP1 ISP2ISP2
BGP Router
BGP Router
Updates
Client BGP
Router
Client BGP
Router
Client BGP
Router
Client BGP
Router
Packets
37Bulk Transfer
Routing ProcessRouting Process
Scaling TP Memory Use
• Store and propagate all BGP routes from ISPs– Separate routing tables
• Reduce memory consumption– Single routing process -
shared data structures– Reduce memory use from
90MB/ISP to 60MB/ISP
ISP1ISP1 ISP2ISP2
Virtual RouterVirtual Router
Virtual RouterVirtual Router
Routing
Table 1
Routing
Table 1
Routing
Table 2
Routing
Table 2
Interactive Service
38Bulk Transfer
Routing ProcessRouting Process
Scaling TP CPU Use
• Hundreds of routing sessions to clients– High CPU load
• Schedule and send routing updates in bundles – Reduces CPU from 18% to
6% for 500 client sessions
ISP1ISP1 ISP2ISP2
Virtual RouterVirtual Router
Virtual RouterVirtual Router
Routing
Table 1
Routing
Table 1
Routing
Table 2
Routing
Table 2
Interactive Service
39
Forwarding TableForwarding Table
Scaling Forwarding Memory
• Connecting clients– Tunneling and VLANs
• Curbing memory usage– Separate virtual routing tables
with default to upstream– 50MB/ISP -> ~0.1MB/ISP
memory use in forwarding table
ISP1ISP1 ISP2ISP2
Virtual BGP
Router
Virtual BGP
Router
Virtual BGP
Router
Virtual BGP
Router
Forwarding Table
1
Forwarding Table
1
Forwardng Table 2Forwardng Table 2
Bulk TransferInteractive Service
top related