VPNs and Network Management EECS 489 Computer Networks

VPNs and Network Management EECS 489 Computer Networks http: //www. eecs. umich. edu/courses/eecs 489/w 07 Z. Morley Mao Monday, April 2, 2007 Acknowledgement: Some slides taken from Kurose&Ross

VPN Taxonomy VPN Network End-to-end Provider-based Customer-based L 3 L 2 ATM Frame Relay LAN

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

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

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

Advantages of original data VPNs r Repeat: a lot cheaper than dedicated leased lines m Corporate users had no other choice m This was the whole business behind frame-relay and ATM services r Fine-grained bandwidth tariffs r Bandwidth guarantees m Service Level Agreements (SLA) r “Multi-protocol”

How has the world changed? r Everything is IP now m Some old stuff still around, but most data networks are just IP r So, why do we still care about VPNs? ? ?

IP VPN benefits r IP not really global (private addresses) m VPN makes separated IP sites look like one private IP network r Security r Bandwidth guarantees across ISP m Qo. S, SLAs r Simplified network operation m ISP can do the routing for you

End-to-end VPNs r Solves problem of how to connect remote hosts to a firewalled network m Security and private addresses benefits only m Not simplicity or Qo. S benefits

End-to-end VPNs r Solves problem of how to connect remote hosts to a firewalled network FW/ VPN Internet IPsec Tunnels Remote Host Site (private network) Site Host

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

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

Customer-based Network VPNs r Great for enterprises that have the resources and skills to do it m Large companies r More control, better security model m Doesn’t require trust in ISP ability and intentions m Can use different ISPs at different sites r But not all enterprises have this skill

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

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

Various PPVPN issues r Provider provisioned VPNs r Tunnel type? m IPsec (more secure, more expensive) m GRE etc. r How to discover which customer is at which PE? m Don’t want PEs without given customer to participate in routing for that customer r How to distinguish overlapping private address spaces

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

Chapter 9 outline r What is network management? r Internet-standard management framework m Structure of Management Information: SMI m Management Information Base: MIB m SNMP Protocol Operations and Transport Mappings m Security and Administration r ASN. 1

What is network management? r autonomous systems (aka “network”): 100 s or 1000 s of interacting hardware/software components r other complex systems requiring monitoring, control: m jet airplane m nuclear power plant m 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. "

Infrastructure for network management definitions: managing entity agent data managing data entity network management protocol managed devices contain managed device managed objects whose data is gathered into a agent data Management Information Base (MIB) managed device agent data managed device

Network Management standards OSI CMIP r Common Management Information Protocol r designed 1980’s: the unifying net management standard r too slowly standardized SNMP: Simple Network Management Protocol r Internet roots (SGMP) r started simple r deployed, adopted rapidly r growth: size, complexity r currently: SNMP V 3 r de facto network management standard

Chapter 9 outline r What is network management? r Internet-standard management framework m Structure of Management Information: SMI m Management Information Base: MIB m SNMP Protocol Operations and Transport Mappings m Security and Administration r ASN. 1

SNMP overview: 4 key parts r Management information base (MIB): m distributed information store of network management data r Structure of Management Information (SMI): m data definition language for MIB objects r SNMP protocol m convey manager<->managed object info, commands r security, administration capabilities m major addition in SNMPv 3

SMI: data definition language Purpose: syntax, semantics of management data welldefined, unambiguous r base data types: m straightforward, boring r OBJECT-TYPE m data type, status, semantics of managed object r MODULE-IDENTITY m groups related objects into MIB module Basic Data Types INTEGER Integer 32 Unsigned 32 OCTET STRING OBJECT IDENTIFIED IPaddress Counter 32 Counter 64 Guage 32 Time Ticks Opaque

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

SMI: Object, module examples OBJECT-TYPE: ip. In. Delivers OBJECT TYPE SYNTAX Counter 32 MAX-ACCESS read-only STATUS current DESCRIPTION “The total number of input datagrams successfully delivered to IP userprotocols (including ICMP)” : : = { ip 9} MODULE-IDENTITY: ip. MIB MODULE-IDENTITY LAST-UPDATED “ 941101000 Z” ORGANZATION “IETF SNPv 2 Working Group” CONTACT-INFO “ Keith Mc. Cloghrie ……” DESCRIPTION “The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes. ” REVISION “ 019331000 Z” ……… : : = {mib-2 48}

MIB example: UDP module Object ID Name Type Comments 1. 3. 6. 1. 2. 1. 7. 1 UDPIn. Datagrams Counter 32 total # datagrams delivered at this node 1. 3. 6. 1. 2. 1. 7. 2 UDPNo. Ports Counter 32 # underliverable datagrams no app at portl 1. 3. 6. 1. 2. 1. 7. 3 UDIn. Errors Counter 32 # undeliverable datagrams all other reasons 1. 3. 6. 1. 2. 1. 7. 4 UDPOut. Datagrams Counter 32 # datagrams sent 1. 3. 6. 1. 2. 1. 7. 5 udp. Table SEQUENCE one entry for each port in use by app, gives port # and IP address

SNMP Naming question: how to name every possible standard object (protocol, data, more. . ) in every possible network standard? ? answer: ISO Object Identifier tree: m hierarchical naming of all objects m each branchpoint has name, number 1. 3. 6. 1. 2. 1. 7. 1 ISO-ident. Org. US Do. D Internet udp. In. Datagrams UDP MIB 2 management

OSI Object Identifier Tree Check out www. alvestrand. no/harald/objectid/top. html

SNMP protocol Two ways to convey MIB info, commands: managing entity request response agent data Managed device request/response mode managing entity trap msg agent data Managed device trap mode

SNMP protocol: message types Message type Get. Request Get. Next. Request Get. Bulk. Request Inform. Request Set. Request Response Trap Function Mgr-to-agent: “get me data” (instance, next in list, block) Mgr-to-Mgr: here’s MIB value Mgr-to-agent: set MIB value Agent-to-mgr: value, response to Request Agent-to-mgr: inform manager of exceptional event

SNMP protocol: message formats

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

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

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. code=‘a’ test. code test. x a 000000011 host 1 format test. code test. x a 00000011 00000001 host 2 format problem: different data format, storage conventions

A real-life presentation problem: grandma 2004 teenager aging 60’s hippie

Presentation problem: potential solutions 1. Sender learns receiver’s format. Sender translates into receiver’s format. Sender sends. 2. Sender sends. Receiver learns sender’s format. Receiver translate into receiver-local format 3. Sender translates host-independent format. Sends. Receiver translates to receiver-local format.

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 grandma aging 60’s hippie 2004 teenager

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

TLV Encoding Idea: transmitted data is self-identifying m T: data type, one of ASN. 1 -defined types m L: length of data in bytes m V: value of data, encoded according to ASN. 1 standard Tag Value 1 2 3 4 5 6 9 Type Boolean Integer Bitstring Octet string Null Object Identifier Real

TLV encoding: example Value, 259 Length, 2 bytes Type=2, integer Value, 5 octets (chars) Length, 5 bytes Type=4, octet string

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

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

Do IP Networks Manage Themselves? r TCP congestion control m Senders react to congestion m Decrease sending rate m But… the TCP sessions receive lower throughput 2 4 2 1 1 3 1 5 4 3 r IP routing protocols m Routers react to failures m Compute new paths m But… the new paths may be congested 2 4 2 1 1 3 1 5 4 3

Do IP Networks Manage Themselves? r In some sense, yes: m TCP senders send less traffic during congestion m Routing protocols adapt to topology changes r But, does the network run efficiently? m Congested link when idle paths exist? m 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 3

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

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

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

Original ARPANET Algorithm (1969) r Routing algorithm m Shortest-path routing based on link metrics m Instantaneous queue length plus a constant m Distributed shortest-path algorithm (Bellman. Ford) 2 3 2 1 1 3 5 1 20 congested link

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

Problem: Out-of-Date Information Lincoln Tunnel NJ NYC Holland Tunnel “Backup at Lincoln” on radio triggers congestion at Holland r Routers make decisions based on old information m Propagation delay in flooding link metrics m Thresholds applied to limit number of updates r Old information leads to bad decisions m All routers avoid the congested links m … leading to congestion on other links m … and the whole things repeats

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

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

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

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

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

Traffic Engineering as a Network-Management Problem: Case Study

Using Traditional Routing Protocols r Routers flood information to learn topology m Determine m Compute “next hop” to reach other routers… shortest paths based on link weights r Link weights configured by network operator 2 3 2 1 1 1 3 5 4 3

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

Example of Tuning the Link Weights r Problem: congestion along the pink path m Second or third link on the path is overloaded r Solution: move some traffic to the bottom path m E. g. , by increasing the weight of the second link 2 3 2 1 1 31 3 5 4 3

Measure, Model, and Control Network-wide “what if” model Offered Topology/ traffic Configuration measure Changes to the network control Operational network

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

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

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

Multiple Shortest Paths: Even Splitting 0. 25 0. 5 1. 0 0. 25 0. 5 Values of Pi, j, l

Defining the Objective Function r Computing the link utilization ul = Si, j Mi, j Pi, j, l m Utilization: ul/cl m Link load: r Objective functions m m min (maxl(ul/cl)) min(Sl f(ul/cl)) f(x) x 1

Complexity of the Optimization Problem r Computationally intractable problem m No efficient algorithm to find the link weights m Even for simple objective functions r What are the implications? m Must resort to searching through weight settings

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

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

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

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

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

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

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

Interdomain Traffic Engineering r Predict effects of changes to import policies m Inputs: routing, traffic, and configuration data m Outputs: flow of traffic through the network Topology Externally learned routes BGP policy configuration BGP routing model Offered traffic Flow of traffic through the network

Outbound Traffic: Pick a BGP Route r Easier to control than inbound traffic m IP routing is destination based m Sender determines where the packets go r Control only by selecting the next hop m Border router can pick the next-hop AS m Cannot control selection of the entire path Provider 1 “(1, 3, 4)” Provider 2 “(2, 7, 8, 4)”

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

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

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

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