VPNs and Network Management

1
VPNs and Network Management

• EECS 489 Computer Networks
• http//www.eecs.umich.edu/courses/eecs489/w07
• Z. Morley Mao
• Monday, April 2, 2007

Acknowledgement Some slides taken from
KuroseRoss
2
VPN Taxonomy
VPN
Network
End-to-end
Provider-based
Customer-based
Provider-based
Customer-based
L3
3
What is a VPN?

• Making a shared network look like a private
  network
• Why do this?
• Private networks have all kinds of advantages
• (well get to that)
• But building a private network is expensive
• (cheaper to have shared resources rather than
  dedicated)

4
History of VPNs

• Originally a telephone network concept
• Separated offices could have a phone system that
  looked like one internal phone system
• Benefits?
• Fewer digits to dial
• Could have different tariffs
• Company didnt have to pay for individual long
  distance calls
• Came with own blocking probabilities, etc.
• Service guarantees better (or worse) than public
  phone service

5
Original data VPNs

• Lots of different network technologies in those
  days
• Decnet, Appletalk, SNA, XNS, IPX,
• None of these were meant to scale to global
  proportions
• Virtually always used in corporate settings
• Providers offer virtual circuits between customer
  sites
• Frame Relay or ATM
• A lot cheaper than dedicated leased lines
• Customer runs whatever network technology over
  these
• These still exist (but being replaced by IP VPNs)

6
Advantages of original data VPNs

• Repeat a lot cheaper than dedicated leased
  lines
• Corporate users had no other choice
• This was the whole business behind frame-relay
  and ATM services
• Fine-grained bandwidth tariffs
• Bandwidth guarantees
• Service Level Agreements (SLA)
• Multi-protocol

7
How has the world changed?

• Everything is IP now
• Some old stuff still around, but most data
  networks are just IP
• So, why do we still care about VPNs???

8
IP VPN benefits

• IP not really global (private addresses)
• VPN makes separated IP sites look like one
  private IP network
• Security
• Bandwidth guarantees across ISP
• QoS, SLAs
• Simplified network operation
• ISP can do the routing for you

9
End-to-end VPNs

• Solves problem of how to connect remote hosts to
  a firewalled network
• Security and private addresses benefits only
• Not simplicity or QoS benefits

10
End-to-end VPNs

• Solves problem of how to connect remote hosts to
  a firewalled network

Site (private network)
Site Host
Internet
FW/ VPN
IPsec Tunnels
Site Host
Remote Host
Remote Host
11
Provider-based end-to-end VPNs

• Used for instance when enterprise pays for
  employee access, wants it to go through
  enterprise network
• I know Cisco did this
• But never used that much
• Business model didnt take off
• Used even less now
• In part because VPN client comes with windows OS?
• The tunneling technology commonly used for
  roaming dialup though

12
Customer-based Network VPNs
Site
Site
CE
CE
Internet
CE
Site
CE
Site
Customer buys own equipment, configures IPsec
tunnels over the global internet, manages
addressing and routing. ISP plays no role.
13
Customer-based Network VPNs

• Great for enterprises that have the resources and
  skills to do it
• Large companies
• More control, better security model
• Doesnt require trust in ISP ability and
  intentions
• Can use different ISPs at different sites
• But not all enterprises have this skill

14
Provider-based Network VPNs
Site
Site
CE
CE
PE
PE
ISP
PE
Site
PE
CE
CE
Site
Provider manages all the complexity of the VPN.
Customer simply connects to the provider
equipment.
15
Model for customer

• Attach to ISP router (PE) as though it was one of
  your routers
• Run routing algorithm with it
• OSPF, RIP, BGP
• PE will advertise prefixes from other sites of
  same customer

16
Various PPVPN issues

• Provider provisioned VPNs
• Tunnel type?
• IPsec (more secure, more expensive)
• GRE etc.
• How to discover which customer is at which PE?
• Dont want PEs without given customer to
  participate in routing for that customer
• How to distinguish overlapping private address
  spaces

17
Chapter 9 Network Management

• Chapter goals
• introduction to network management
• motivation
• major components
• Internet network management framework
• MIB management information base
• SMI data definition language
• SNMP protocol for network management
• security and administration
• presentation services ASN.1

18
Chapter 9 outline

• What is network management?
• Internet-standard management framework
• Structure of Management Information SMI
• Management Information Base MIB
• SNMP Protocol Operations and Transport Mappings
• Security and Administration
• ASN.1

19
What is network management?

• autonomous systems (aka network) 100s or 1000s
  of interacting hardware/software components
• other complex systems requiring monitoring,
  control
• jet airplane
• nuclear power plant
• others?

"Network management includes the deployment,
integration and coordination of the hardware,
software, and human elements to monitor, test,
poll, configure, analyze, evaluate, and control
the network and element resources to meet the
real-time, operational performance, and Quality
of Service requirements at a reasonable cost."
20
Infrastructure for network management
definitions
managing entity
managed devices contain managed objects whose
data is gathered into a Management
Information Base (MIB)
managed device
network management protocol
managed device
managed device
managed device
21
Network Management standards

• OSI CMIP
• Common Management Information Protocol
• designed 1980s the unifying net management
  standard
• too slowly standardized

• SNMP Simple Network Management Protocol
• Internet roots (SGMP)
• started simple
• deployed, adopted rapidly
• growth size, complexity
• currently SNMP V3
• de facto network management standard

22
Chapter 9 outline

• What is network management?
• Internet-standard management framework
• Structure of Management Information SMI
• Management Information Base MIB
• SNMP Protocol Operations and Transport Mappings
• Security and Administration
• ASN.1

23
SNMP overview 4 key parts

• Management information base (MIB)
• distributed information store of network
  management data
• Structure of Management Information (SMI)
• data definition language for MIB objects
• SNMP protocol
• convey managerlt-gtmanaged object info, commands
• security, administration capabilities
• major addition in SNMPv3

24
SMI data definition language

• Purpose syntax, semantics of management data
  well-defined, unambiguous
• base data types
• straightforward, boring
• OBJECT-TYPE
• data type, status, semantics of managed object
• MODULE-IDENTITY
• groups related objects into MIB module

Basic Data Types
INTEGER Integer32 Unsigned32 OCTET STRING OBJECT
IDENTIFIED IPaddress Counter32 Counter64 Guage32 T
ime Ticks Opaque
25
SNMP MIB

MIB module specified via SMI MODULE-IDENTITY (100
standardized MIBs, more vendor-specific)
OBJECT TYPE
OBJECT TYPE
OBJECT TYPE
objects specified via SMI OBJECT-TYPE construct
26
SMI Object, module examples

• MODULE-IDENTITY ipMIB

• OBJECT-TYPE ipInDelivers

ipMIB MODULE-IDENTITY LAST-UPDATED
941101000Z ORGANZATION IETF SNPv2
Working Group CONTACT-INFO Keith
McCloghrie DESCRIPTION The MIB
module for managing IP and ICMP
implementations, but excluding their
management of IP routes. REVISION
019331000Z mib-2 48
ipInDelivers OBJECT TYPE SYNTAX
Counter32 MAX-ACCESS read-only STATUS
current DESCRIPTION The total number of
input datagrams successfully
delivered to IP user- protocols (including
ICMP) ip 9
27
MIB example UDP module
Object ID Name Type
Comments 1.3.6.1.2.1.7.1 UDPInDatagrams
Counter32 total datagrams delivered

at this node 1.3.6.1.2.1.7.2
UDPNoPorts Counter32 underliverable
datagrams no app at
portl 1.3.6.1.2.1.7.3 UDInErrors
Counter32 undeliverable datagrams
all other reasons 1.3.6.1.2.1.7.4
UDPOutDatagrams Counter32 datagrams
sent 1.3.6.1.2.1.7.5 udpTable SEQUENCE
one entry for each port in use by
app, gives port and IP address
28
SNMP Naming

• question how to name every possible standard
  object (protocol, data, more..) in every possible
  network standard??
• answer ISO Object Identifier tree
• hierarchical naming of all objects
• each branchpoint has name, number

1.3.6.1.2.1.7.1
udpInDatagrams UDP MIB2 management
ISO ISO-ident. Org. US DoD Internet
29
OSI Object Identifier Tree
Check out www.alvestrand.no/harald/objectid/top.ht
ml
30
SNMP protocol

• Two ways to convey MIB info, commands

trap msg
response
Managed device
Managed device
request/response mode
trap mode
31
SNMP protocol message types
Message type
Function
GetRequest GetNextRequest GetBulkRequest
Mgr-to-agent get me data (instance,next in
list, block)
InformRequest
Mgr-to-Mgr heres MIB value
SetRequest
Mgr-to-agent set MIB value
Agent-to-mgr value, response to Request
Response
Agent-to-mgr inform manager of exceptional event
Trap
32
SNMP protocol message formats
33
SNMP security and administration

• encryption DES-encrypt SNMP message
• authentication compute, send MIC(m,k) compute
  hash (MIC) over message (m), secret shared key
  (k)
• protection against playback use nonce
• view-based access control
• SNMP entity maintains database of access rights,
  policies for various users
• database itself accessible as managed object!

34
Chapter 9 outline

• What is network management?
• Internet-standard management framework
• Structure of Management Information SMI
• Management Information Base MIB
• SNMP Protocol Operations and Transport Mappings
• Security and Administration
• The presentation problem ASN.1

35
The presentation problem

• Q does perfect memory-to-memory copy solve the
  communication problem?
• A not always!

struct char code int x
test test.x 256 test.codea
test.code test.x
test.code test.x
host 2 format
host 1 format
problem different data format, storage
conventions
36
A real-life presentation problem
grandma
2004 teenager
aging 60s hippie
37
Presentation problem potential solutions

• 1. Sender learns receivers format. Sender
  translates into receivers format. Sender sends.
• 2. Sender sends. Receiver learns senders format.
  Receiver translate into receiver-local format
• 3. Sender translates host-independent format.
  Sends. Receiver translates to receiver-local
  format.

38
Solving the presentation problem

• 1. Translate local-host format to
  host-independent format
• 2. Transmit data in host-independent format
• 3. Translate host-independent format to
  remote-host format

aging 60s hippie
2004 teenager
grandma
39
ASN.1 Abstract Syntax Notation 1

• ISO standard X.680
• used extensively in Internet
• like eating vegetables, knowing this good for
  you!
• defined data types, object constructors
• like SMI
• BER Basic Encoding Rules
• specify how ASN.1-defined data objects to be
  transmitted
• each transmitted object has Type, Length, Value
  (TLV) encoding

40
TLV Encoding

• Idea transmitted data is self-identifying
• T data type, one of ASN.1-defined types
• L length of data in bytes
• V value of data, encoded according to ASN.1
  standard

Tag Value Type
Boolean Integer Bitstring Octet
string Null Object Identifier Real
1 2 3 4 5 6 9
41
TLV encoding example
Value, 259 Length, 2 bytes Type2, integer
Value, 5 octets (chars) Length, 5 bytes Type4,
octet string
42
Network Management summary

• network management
• extremely important 80 of network cost
• ASN.1 for data description
• SNMP protocol as a tool for conveying information
• Network management more art than science
• what to measure/monitor
• how to respond to failures?
• alarm correlation/filtering?

43
(No Transcript)
44
Examples of network management

• Challenges
• Reacting quickly to alleviate congestion
• Avoiding over-reacting and causing oscillations
• Limiting bandwidth CPU overhead on routers
• Load-sensitive routing
• Routers adapt to link load in a distributed
  fashion
• At the packet level, or on group of packets
• Traffic engineering
• Centralized computation of routing parameters
• Network-wide measurements of offered traffic

45
Do IP Networks Manage Themselves?

• TCP congestion control
• Senders react to congestion
• Decrease sending rate
• But the TCP sessions receive lower throughput

• IP routing protocols
• Routers react to failures
• Compute new paths
• But the new paths may be congested

2
2
1
1
4
4
1
1
3
3
2
2
1
1
5
5
4
4
3
3
46
Do IP Networks Manage Themselves?

• In some sense, yes
• TCP senders send less traffic during congestion
• Routing protocols adapt to topology changes
• But, does the network run efficiently?
• Congested link when idle paths exist?
• High-delay path when a low-delay path exists?

2
2
1
1
4
4
1
1
3
3
2
2
1
1
5
5
4
4
3
3
47
Adapting the Routing to the Traffic

• Goal modify the routes to steer traffic through
  the network in most effective way
• Approach 1 load-sensitive protocols
• Distribute traffic performance measurements
• Routers compute paths based on load
• Approach 2 adaptive management system
• Collect measurements of traffic and topology
• Management system optimizes the parameters
• Debates still today about the right answer

48
Load-Sensitive Routing Protocols

• Advantages
• Efficient use of network resources
• Satisfying the performance needs of end users
• Self-managing network takes care of itself
• Disadvantages
• Higher overhead on the routers
• Long alternate paths consume extra resources
• Instability from out-of-date feedback information

49
Packet-Based Load-Sensitive Routing

• Packet-based routing
• Forward packets based on forwarding table
• Load-sensitive
• Compute table entries based on load or delay
• Questions
• What link metrics to use?
• How frequently to update the metrics?
• How to propagate the metrics?
• How to compute the paths based on metrics?

50
Original ARPANET Algorithm (1969)

• Routing algorithm
• Shortest-path routing based on link metrics
• Instantaneous queue length plus a constant
• Distributed shortest-path algorithm (Bellman-Ford)

2
1
3
1
3
2
1
5
20
congested link
51
Performance of ARPANET Algorithm

• Light load
• Delay dominated by transmission propagation
• So, link metrics dont fluctuate much
• Medium load
• Queuing delay is no longer negligible
• Moderate traffic shifts to avoid congestion
• Heavy load
• Very high metrics on congested links
• Busy links look bad to all of the routers
• All routers avoid the busy links
• Routers may send packets on longer paths

52
Problem Out-of-Date Information

• Routers make decisions based on old information
• Propagation delay in flooding link metrics
• Thresholds applied to limit number of updates
• Old information leads to bad decisions
• All routers avoid the congested links
• leading to congestion on other links
• and the whole things repeats

53
Problem Frequent Updates

• Update messages
• Link keeps track of its metric (e.g., queuing
  delay)
• Link transmits updates when the metric changes
• Frequency of updates
• Frequent changes to the metric lead to frequent
  updates
• Significantly increases the overhead of the
  protocol
• Oscillation makes the problem worse
• Oscillation leads to wild swings in the link
  metrics
• Forcing very frequent update messages
• that add to the load on the links in the network

54
Second ARPANET Algorithm (1979)

• Link-state protocol
• Old Distributed path computation leads to loops
• New Better to flood metrics and have each router
  compute the shortest paths
• Averaging of the link metric over time
• Old Instantaneous delay fluctuates a lot
• New Averaging reduces the fluctuations
• Reduce frequency of updates
• Old Sending updates on each change is too much
• New Send updates if change passes a threshold

55
Problem of Long Alternate Paths

• Picking alternate paths
• Long path chosen by one router consumes resource
  that other packets could have used
• Leads other routers to pick other alternate paths
• Solution limit path length
• Bound the value of the link metric
• This link is busy enough to go two extra hops
• Extreme case
• Limit path selection to the shortest paths
• Pick least-loaded shortest path in the network

56
Load-Sensitive Routing

• Timescales
• What timescale of routing decisions?
• What timescale of feedback about link loads?
• Load-sensitive routing at packet level
• Routers receive feedback on load and delay
• Routers re-compute their forwarding tables
• Fundamental problems with oscillation
• Load-sensitive routing for groups of packets
• Routers receive feedback on load and delay
• Router compute a path for the next flow or
  circuit
• Less oscillation, as long as circuits last for a
  while

57
Reducing Effects of Out-of-Date Info

• Send link metrics more often
• But, leads to higher overhead
• But, propagation delay is a fundamental limit
• Make the traffic last longer
• Route on groups of packets, rather than packets
• Fewer routing decisions, and more accurate
  feedback
• Groups of packets
• Telephone network phone call (3-minutes long)
• Internet TCP connection (10-packets long)
• Internet all traffic between a pair of hosts, or
  routers,

58
Traffic Engineering as a Network-Management
Problem Case Study
59
Using Traditional Routing Protocols

• Routers flood information to learn topology
• Determine next hop to reach other routers
• Compute shortest paths based on link weights
• Link weights configured by network operator

60
Approaches for Setting the Link Weights

• Conventional static heuristics
• Proportional to physical distance
• Cross-country links have higher weights
• Minimizes end-to-end propagation delay
• Inversely proportional to link capacity
• Smaller weights for higher-bandwidth links
• Attracts more traffic to links with more capacity
• Tune the weights based on the offered traffic
• Network-wide optimization of the link weights
• Directly minimize metrics like max link
  utilization

61
Example of Tuning the Link Weights

• Problem congestion along the pink path
• Second or third link on the path is overloaded
• Solution move some traffic to the bottom path
• E.g., by increasing the weight of the second link

2
1
3
1
3
2
3
1
5
4
3
62
Measure, Model, and Control
Network-wide what if model
Offered traffic
Changes to the network
Topology/ Configuration
measure
control
Operational network
63
Traffic Engineering Problem

• Topology
• Connectivity and capacity of routers and links
• Traffic matrix
• Offered load between points in the network
• Link weights
• Configurable parameters for routing protocol
• Performance objective
• Balanced load, low latency, service level
  agreements
• Question Given the topology and traffic matrix,
  which link weights should be used?

64
Key Ingredients of the Approach

• Instrumentation
• Topology monitoring of the routing protocols
• Traffic matrix fine-grained traffic measurement
• Network-wide models
• Representations of topology and traffic
• What-if models of shortest-path routing
• Network optimization
• Efficient algorithms to find good configurations
• Operational experience to identify key
  constraints

65
Formalizing the Optimization Problem

• Input graph G(R,L)
• R is the set of routers
• L is the set of unidirectional links
• cl is the capacity of link l
• Input traffic matrix
• Mi,j is load from router i to j
• Output setting of the link weights
• wl is weight on unidirectional link l
• Pi,j,l is fraction of traffic from i to j
  traversing link l

66
Multiple Shortest Paths Even Splitting
Values of Pi,j,l
67
Defining the Objective Function

• Computing the link utilization
• Link load ul Si,j Mi,j Pi,j,l
• Utilization ul/cl
• Objective functions
• min (maxl(ul/cl))
• min(Sl f(ul/cl))

68
Complexity of the Optimization Problem

• Computationally intractable problem
• No efficient algorithm to find the link weights
• Even for simple objective functions
• What are the implications?
• Must resort to searching through weight settings

69
Optimization Based on Local Search

• Start with an initial setting of the link weights
• E.g., same integer weight on every link
• E.g., weights inversely proportional to capacity
• E.g., existing weights in the operational network
• Compute the objective function
• Compute the all-pairs shortest paths to get
  Pi,j,l
• Apply the traffic matrix Mi,j to get link loads
  ul
• Evaluate the objective function from the ul/cl
• Generate a new setting of the link weights

repeat
70
Making the Search Efficient

• Avoid repeating the same weight setting
• Keep track of past values of the weight setting
• or keep a small signature of past values
• Do not evaluate setting if signatures match
• Avoid computing shortest paths from scratch
• Explore settings that changes just one weight
• Apply fast incremental shortest-path algorithms
• Limit number of unique link-weight values
• Dont explore 216 possible values for each weight
• Stop early, before exploring all settings

71
Incorporating Operational Realities

• Minimize number of changes to the network
• Changing just 1 or 2 link weights is often enough
• Tolerate failure of network equipment
• Weights usually remain good after failure
• or can be fixed by changing 1-2 weights
• Limit effects of measurement accuracy
• Good weights remain good, despite noise
• Limit frequency of changes to the weights
• Joint optimization for day night traffic
  matrices

72
Application to ATTs Backbone

• Performance of the optimized weights
• Search finds a good solution within a few minutes
• Much better than link capacity or physical
  distance
• Competitive with multi-commodity flow solution
• How ATT changes the link weights
• Maintenance every night from midnight to 6am
• Predict effects of removing link(s) from network
• Reoptimize the link weights to avoid congestion
• Configure new weights before disabling equipment

73
Example from ATTs Operations Center

• Amtrak repairing/moving part of train track
• Need to move some of the fiber optic cables
• Or, heightened risk of the cables being cut
• Amtrak notifies ATT the timework will be done
• ATT engineers model the effects
• Determine which IP links go over affected fiber
• Pretend the network no longer has these links
• Evaluate the new shortest paths and traffic flow
• Identify whether link loads will be too high

74
Example Continued

• If load will be too high
• Reoptimize the weights on the remaining links
• Schedule time for new weights to be configured
• Roll back to old weights when Amtrak is done
• Same process applied to other cases
• Assessing the networks risk to possible failures
• Planning for maintenance of existing equipment
• Adapting link weights to installation of new
  links
• Adapting link weights in response to traffic
  shifts

75
What About Interdomain Routing?

• Border Gateway Protocol
• Announcements carry very limited information
• E.g., AS path, but nothing about delay, loss,
  etc.
• Challenging to make load-sensitive protocol
• Hard to agree upon a common metric
• Hard to scale to such a large network
• Hard to prevent ASes from gaming the system
• Instead, individual ASes act alone
• Change routing policies based on link load
• E.g., moving some traffic to another provider

76
Interdomain Traffic Engineering

• Predict effects of changes to import policies
• Inputs routing, traffic, and configuration data
• Outputs flow of traffic through the network

BGP policy configuration
Topology
Externally learned routes
BGP routing model
Offered traffic
Flow of traffic through the network
77
Outbound Traffic Pick a BGP Route

• Easier to control than inbound traffic
• IP routing is destination based
• Sender determines where the packets go
• Control only by selecting the next hop
• Border router can pick the next-hop AS
• Cannot control selection of the entire path

Provider 1
Provider 2
(1, 3, 4)
(2, 7, 8, 4)
78
Outbound Traffic Shortest AS Path

• No import policy on border router
• Pick route with shortest AS path
• Arbitrary tie break (e.g., smallest router-id)
• Performance?
• Shortest AS path is not necessarily best
• Could have high delays or congestion
• Load balancing?
• Could lead to uneven split in traffic
• E.g., one provider with shorter paths
• E.g., too many ties with skewed tie-break

79
Outbound Traffic Load Balancing

• Selectively use each provider
• Assign local-pref across destination prefixes
• Change the local-pref assignments over time
• Useful inputs to load balancing
• End-to-end path performance data
• E.g., active measurements along each path
• Outbound traffic statistics per destination
  prefix
• E.g., packet monitors or router-level support
• Link capacity to each provider
• Billing model of each provider

80
Balancing Load, Performance, and Cost

• Balance traffic based on link capacity
• Measure outbound traffic per prefix
• Select provider per prefix for even load
  splitting
• But, might lead to poor performance and high bill
• Balance traffic based on performance
• Select provider with best performance per prefix
• But, might lead to congestion and a high bill
• Balance traffic based on financial cost
• Select provider per prefix over time to minimize
  the total financial cost
• But, might lead to bad performance

81
Conclusions

• Adapting routing to the traffic
• To alleviate congestion
• To minimize propagation delay
• To be robust to future failures
• Two main approaches
• Load-sensitive routing protocol
• Optimization of configurable parameters