Virtual Private Networks:
Progress and Challenges
Panel Session
Copyright © 2000, Juniper Networks, Inc.
Panel Objectives
•
Introduce Virtual Private Network concepts
and technologies
•
Describe some potential service provider
VPN offerings
•
List challenges faced by service providers in
offering VPN services
•
List and describe some of the proposals for
addressing VPN challenges
Copyright © 2000, Juniper Networks, Inc.
Slide 2
Panel Participants
•
Paul Ferguson – Cisco Systems
•
David O’Leary – Juniper Networks
•
Keerti Melkote – Nortel Networks
•
NANOG audience (Question and Answer)
Copyright © 2000, Juniper Networks, Inc.
Slide 3
Virtual Private Networks:
Progress and Challenges
David O’Leary
Director, Consulting Engineering
Copyright © 2000, Juniper Networks, Inc.
What is a VPN?
•
Virtual
•
•
•
Emulation of a private network facilities over a
shared network infrastructure
Private
•
Minimally: no mixing with traffic outside the
VPN, and support for private address space(s)
•
Possibly encryption and protected traffic class
Network – two or more users or sites
Copyright © 2000, Juniper Networks, Inc.
Slide 5
How Virtual is Virtual?
•
The only true non-virtual private network are
customer-owned physical plant, like copper and
fiber, transport and switching equipment
•
Leasing TDM circuits from a carrier means that the
customer gets a “virtual” slice of the carrier’s
transmission network
•
Leasing some kind of layer 2 circuits (ATM, Frame
Relay) from a carrier means that the customer gets
a “virtual” slice of the carrier’s layer 2 network
•
Statistical multiplexing here means that it’s cheaper for
both the provider and (in theory) the customer
Copyright © 2000, Juniper Networks, Inc.
Slide 6
Focus on “IP VPNs”
• VPNs over an IP backbone that supports
multiple services (e.g., public Internet,
VoIP)
•
Exploit economies of scale through use of
common backbone facilities
•
Reduce inefficiencies of separate networks
•
Shared local loops for internal corporate
network and Internet access
•
Service providers add value by allowing
customers (enterprises networks) to
“outsource” their routing (complexity) to the
carrier
Copyright © 2000, Juniper Networks, Inc.
Slide 7
Four models of VPNs
•Remote User access
•CPE Based
•MPLS-based Layer2
•Provider-Based Layer 3
Copyright © 2000, Juniper Networks, Inc.
Slide 8
Remote User Access
•
Variety of protocols developed in mid-90’s
to tunnel remote user traffic to a fixed site
on the IP network
•
ATMP, PPTP, ATMP
•
Functions consolidated in IETF L2TP protocol
•
Documented in RFC 2661, with various drafts for
extensions
•
Dynamic, authenticated tunnels
•
Deployments are becoming quite common
Copyright © 2000, Juniper Networks, Inc.
Slide 9
CPE Based VPNs
• Tunnels configured between CPE devices
• Options are GRE, IPSEC, IP-in-IP, PPTP, L2TP
• Topology of the VPN is configured into the CPE devices
• The provider does not have to do anything to their
network (they may not even know it is happening)
• VPN traffic may be marked and prioritized
•
The service provider may bundle and manage the
CPE devices used to create the VPN service
•
Provides “value add” beyond best effort Internet
connectivity
•
This model is already being aggressively deployed by
providers around the world
Copyright © 2000, Juniper Networks, Inc.
Slide 10
CPE Based VPNs Tradeoffs
•
•
Provider network configuration
•
Potentially no more than required for Internet access
•
CoS or managed service adds provider complexity
Customer (CPE) configuration
•
•
Every tunnel is a separate virtual interface that must be
configured, including for routing
Scalability
•
Provider network – excellent
•
Customer – depends on number of tunnels and routing
topology/complexity
Copyright © 2000, Juniper Networks, Inc.
Slide 11
Layer-2 VPNs
•
•
A subscriber leases VCs between the sites that need
to be connected
•
Topologies are hub and spoke, full or partial mesh
•
The subscriber and provider think of these VCs as “dumb”
pipes not at all involved in Layer 3 issues such as routing,
packet filtering, etc.
•
Subscriber outsources the Layer 3 management to the
provider in a “Managed Router” service
Mature support for commitments about service
(e.g., bandwidth, availability, etc.)
•
At least in the business/SLA sense
•
Virtual Circuit model eases capacity planning
Copyright © 2000, Juniper Networks, Inc.
Slide 12
Layer-2 VPN Tradeoffs
•
Provider configuration
•
•
•
•
A lot in theory, but it’s mostly automated in practice
Subscriber configuration
•
Every VC is a separate virtual interface that must be
configured, including for routing
•
Large, complex topologies yield complex configurations
Scalability
•
Provider -- number of VCs and stability of core
•
Subscriber -- number of interfaces and routing
Other
•
Leverages existing investment
Copyright © 2000, Juniper Networks, Inc.
Slide 13
MPLS-Based Layer-2 VPNs
•
Looks identical to “traditional layer 2 VPNs” from
the subscriber perspective
•
Provider carries the layer 2 circuits over an
IP/MPLS backbone
•
Provides the ability for multiple services (public IP,
private IP, VoIP, etc) over a single access circuit
Copyright © 2000, Juniper Networks, Inc.
Slide 14
MPLS-Based Layer-2 VPNs
Internet Traffic:
ATM VC1 terminated, IP packets delivered to provider 2
Provider 2
Provider 1
Subscriber A
ATM Access
ATM Access
Subscriber A
VPN Traffic:
ATM VC2 mapped to MPLS LSP “tunnel”
Termination of ATM PVCs (layer 3 lookup) and support Layer-2 passthrough on the same port.
Copyright © 2000, Juniper Networks, Inc.
Slide 15
MPLS-Based Layer-2 VPN Tradeoffs
•
Provider configuration
•
•
•
Manual configuration of ingress and egress
boxes (could be partially automated)
Subscriber configuration
•
Every VC is a separate virtual interface that
must be configured, including for routing
•
Retains existing CPE and subscriber model
Scalability
•
Provider -- number of LSPs, stability of core
•
Subscriber -- number of VCs and routing
Copyright © 2000, Juniper Networks, Inc.
Slide 16
Provider-Based Layer-3 VPNs
•
Concepts outlined in RFC 2547 and RFC 2764
•
Subscriber treats access link as combined
internet/VPN link
•
Except for multiply-connected sites, needs minimal
configuration (i.e., Default)
•
Provider’s edge router supports instances of routing
protocols and multiple forwarding tables
•
•
If a destination isn’t in a VPN-specific forwarding table
then use Internet table
VPN site membership and VPN-specific routing
information carried in BGP
•
Supports overlapping private address space
•
Topology is conceptually always a full mesh between PE’s
Copyright © 2000, Juniper Networks, Inc.
Slide 17
Provider-based Layer-3 VPN tradeoffs
• Provider configuration
• Minimal static configuration in basic scenarios
• More configuration needed for complex topologies
• Subscriber configuration
• Basic scenario is straightforward
• More complex config needed for security, multihoming,
participation in multiple VPNs, etc.
• Scalability
• Provider
• I-BGP possibly sees 100,000s of routes, (in)stability of
multiple dynamic routing domains, multiple forwarding
tables
• Subscriber – allows shared local loop and CPE device for
multiple services (intranet, Internet, voice, etc.)
Copyright © 2000, Juniper Networks, Inc.
Slide 18
Where Does That Leave Us?
• Customer-centric tunneling are easier for the
provider
• COS, traffic engineering, SLA’s, etc. are value-adds
• For a provider implementing VPNs, scalability and
value-add are fundamentally at odds
• MPLS-based layer-2 VPNs offer the benefits of an
integrated/multi-service network
• But the enterprise network has to handle the routing
• Layer-3 VPNs allow the enterprise network to be almost
unconcerned with routing
• Doesn’t support as many VPNs, sites per VPN, routes per VPN
or customers per access box than MPLS-based layer 2 VPNs
• Risk of the stability of the multi-service core
• So what is the answer?
Copyright © 2000, Juniper Networks, Inc.
Slide 19
Where Does That Leave Us? (cont.)
•
The answer is: it depends
•
Some subscribers may require the ability to outsource routing
•
•
Layer 3 VPNs or
•
MPLS-based layer 2 VPNs where “managed services” are
provided and a device at the customer’s premises converts from
pure IP to some number of layer 2 virtual circuits
Some subscribers may be capable of doing their own routing
•
•
MPLS-based layer 2 VPNs offer scalability for broad deployment
as well as stability with less coupling
Range of hybrid solutions is probably likely
•
Remote access user VPNs
•
CPE-based VPNs
•
MPLS-based layer 2 VPNs
•
Layer 3 VPNs
Copyright © 2000, Juniper Networks, Inc.
Slide 20
Summary
•
There is no one-size-fits-all solution for
VPNs
•
Tradeoffs between value add and
scalability/stability
•
Tradeoffs between customer requirements
•
Desire to outsource routing, security, etc.
•
Size and complexity of network
Copyright © 2000, Juniper Networks, Inc.
Slide 21