Transcript Multiplexing BGP Sessions with BGP-Mux

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
Autonomous Systems
Route Advertisement
Traffic
Session
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
BGP Sessions
Virtual
AS1
GENI, ProtoGENI, VINI
Virtual
AS2
Solution: BGP Mux
AS1
AS2
BGP-Mux
Virtual
AS1
Virtual
AS2
GENI, ProtoGENI, VINI
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
AS2
BGP-View –
AS2
BGP-View –
AS1
External IP
BGP Instance
BGP-Mux Server
AS1
IP1
Virtual
AS1
IP2
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
!
BGP Server
AS1
BGP Server
BGP-View –
AS2
BGP-View –
AS1
BGP Instance
BGP-Mux Server
Scaling with Multiple Views
AS2
External 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