Advanced DHCP and DNS Deployments

Advanced DHCP and DNS Deployments
BRKNMS-2640
Bernie Volz
Introduction
This session describes the management of IP addresses (host and domain) names. We explain the functionalities of DHCP and DNS and how they collaborate to produce the foundation of a name and address management system. The recent developments in both areas will be touched as well. Finally we enumerate best practices for achieving reliability and security of both services.
BRKNMS-2640
2011 Cisco and/or its affiliates. All rights reserved.
Cisco Public
Non-Information
Silence your phone, pda, pager, mp3 player
At CiscoLive! your evaluation is extremely important Please remember to wear your badge at all times Please visit the World of Solutions
There is extra material in the appendix at the end of this presentation; the explanatory notes contain links to reference material; I tried to translate all acronyms You can ask questions any time
BRKNMS-2640
Cisco Public
Meet the Engineer

To make the most of your time at Networkers at Cisco Live 2011, schedule a Face-to-Face Meeting with top Cisco Engineers. Designed to provide a "big picture" perspective as well as "in-depth" technology discussions, these faceto-face meetings will provide fascinating dialogue and a wealth of valuable insights and ideas. Visit the Meeting Centre reception desk located in the Meeting Centre in World of Solutions.
BRKNMS-2640
Cisco Public
What You Will Learn

Managing addresses with DHCP
Concepts, protocols Scale & Reliability IPv6
Coordination between DNS and DHCP services Providing reliable and secure name and address services
BRKNMS-2640
Cisco Public
Dynamic Host Configuration Protocol DHCP

DHCP Scale Considerations DHCP Reliability Considerations IPv6 and DHCP
Domain Name System DNS

Interaction Between DNS and DHCP
Managing the DHCP Server

DHCP Server Acts as Agent for Network Administrator
Server configured with:

Network design (Layer 3): network segments, subnets, relay agents
Available addresses Rules about address allocation
Network administrator controls DHCP service

Policies for hosts or groups of hosts Specific configuration parameters
Which hosts to serve
BRKNMS-2640
Cisco Public
DHCP Leases Network Configuration

Administrator creates pools of addresses available for assignment to hosts Server dynamically assigns IP address on demand with a lease time attribute Client can ask to extend lease time Server may reassign address after lease expires
DHCP Client
Here is Your Configuration: IP Address: 192.168.18.7 Subnet Mask: 255.255.255.0 Default Routers: 192.168.18.1, 192.168.18.3 DNS Servers: 192.168.1.8, 192.168.1.9 Lease Time: 5 days
DHCP Server
Send My Configuration Information
DHCP delivers other configuration information in options

BRKNMS-2640
Cisco Public
Basic DHCP Message Exchange

Server 1 Client broadcasts DHCPDISCOVER message on local subnet Client Server 2
Servers send DHCPOFFER messages with lease information Client selects lease and broadcasts DHCPREQUEST message
Selected server sends DHCPACK message
BRKNMS-2640
Cisco Public
Refresh Lease Sequence

At 50% of lease time, Client refreshes lease and unicasts DHCPREQUEST message.
Client Server
Selected server sends DHCPACK message, extending the lease.

If server sends a DHCPNACK, the client restarts the full lease cycle (previous slide). If no answer, the lease stays valid until lease time expires and client should retry.
BRKNMS-2640
Cisco Public
10


Architectures for DHCP Service (1)

Distributed DHCP Service Centralized DHCP Service
DHCP Server
DHCP Server
DHCP Relay Agent
Pro: Reliability Through redundancy
DHCP Server
Pro: Centralized Management
DHCP Relay Agent
BRKNMS-2640
Cisco Public
12
The Cisco IOS DHCP Server at Work

DHCP Server
Camera
Server
Sensor
Printer
Wireless AP
Static DHCP client : per port or per Client-id or MAC address
Range per type of clients (PC, sensor, etc.) Secures the LAN by coupling DHCP lease to ARP cache Manage your pools with syslog on threshold, MIB, and accounting Update the upstream DNS server from DHCP bindings
BRKNMS-2640
Cisco Public
13
Architectures for DHCP Service (2)

Hybrid DHCP Service
DHCP Server
Redundant DHCP Service

DHCP Servers
DHCP Server
DHCP Relay Agent
Remote Site
DHCP Relay Agents
DHCP Relay Agent
Pro: Independent Operation of Remote Site if WAN Link Fails
Pro: Reliability Through Redundancy with Failover

BRKNMS-2640
Cisco Public
14
Best of Both Worlds

Hybrid DHCP Service
DHCP Servers
Delegation
DHCP Server
Remote Site
DHCP Relay Agents
BRKNMS-2640
Cisco Public
15
Automating Address
Pool Assignment
IPv4 has limited addresses in each subnet

DHCP service must be configured with pools of available addresses ODAP allows dynamic reallocation of address pools
DHCP extensions for dynamic pool assignment

Dynamic allocation of subnet(s) to DHCP pool configured on network element Automatic insertion of summarized route to appropriate routing table for allocated subnet Hierarchical DHCP
Improves efficiency of DHCP address assignment by moving available addresses to meet demand
BRKNMS-2640
Cisco Public
16
For Millions of Subscribers

Slave Servers Redundant Master Servers
DHCP Relay Agent
Delegation
DHCP Relay Agent IOS Slave Servers
BRKNMS-2640
Cisco Public
17
Cisco Network Registrar

Local clusters - Standards-compliant DNS, DHCP, and TFTP services for IPv4 and IPv6
Regional cluster - Central Configuration and Monitoring Fast and Scalable
Distributed architecture, supports millions of subscribers in some of the largest deployments in the world
Extensible and Customizable

Software hooks that let administrators intercept protocol messages and extend server behavior
Regional Cluster
Easy to Integrate
API, CLI, and SNMP to facilitate automation and control
Highly-Available
DHCP failover (v4) HA-DNS
Backup Cluster Local Cluster
BRKNMS-2640

Cisco Public
18

DHCP Scale Considerations DHCP Reliability Considerations
IPv6 and DHCP

Reliable DHCP Service

Problem: provide increased reliability for DHCP service through redundancy
Solution: deploy multiple DHCP servers and enable all servers to respond to messages
DHCP client broadcasts messages, and relay agent can forward to multiple servers, so more than one DHCP server may receive messages from clients DHCP client is required by protocol specification to be able to receive responses from multiple servers
DHCP client broadcasts rebinding request, so it can locate secondary server if primary is not accessible
BRKNMS-2640
Cisco Public
20
But Independent Servers have Issues

Requires much more address space (2 times)
If original server is down when client re-connects or during renewal process:

Client must change address (remaining server has different address space)
Original servers lease still marked as in use until it expires as it doesnt know client has changed addresses
If DNS is updated, both addresses in DNS If leasequery done, both servers might respond with active lease information
BRKNMS-2640
Cisco Public
21
Better if Servers Shared State

Servers notify each other of assignments
If assigning server fails, other server(s) will have a record of the assignment and can respond
However, notification may take some time
DHCP specification does not allow sufficient time to do update before responding
Most hosts will timeout and retransmit before the interserver update completes
Therefore, server cant wait for update to complete before sending response
BRKNMS-2640
Cisco Public
22
Solution . DHCP Safe Failover

Backup DHCP Server
Main DHCP Server
Main Address Pool 192.168.18.101-150
Backup Address Pool 192.168.18.151-200
BRKNMS-2640
Cisco Public
23
Safe Failover Requirements and Goals

Requirements
Compatible with RFC 2131 clients Provide for coordination between servers not located on the same subnet No duplicate IP address assignment when one server fails
Goals
Client keeps existing address if communicating with either server
Client can get new address from either available server
Server can recover lost database from other server
BRKNMS-2640
Cisco Public
24
Failover With Both Servers Operational
Shhhhh
5. DHCPBNDUPD 6. DHCPBNDACK
1. DHCPDISCOVER
Backup
Backup Pool: 201-254
Client
2. DHCPOFFER Any Address Between 1-200
Main
4. DHCPACK Any Address Between 1-200
Address Pool: Main Pool: 10.10.10.1-254 1-200

BRKNMS-2640
Cisco Public
25
Failover When Only Backup Operational

COMMUNICATIONSINTERRUPTED STATE DHCPPOLL
2. DHCPOFFER Any Address Between 201-254
Backup
Backup Pool: 201-254
1. DHCPDISCOVER
Client
Main
Address Pool: Main Pool: 10.10.10.1-254 1-200
BRKNMS-2640
Backup Uses Backup Pool for New Clients
Cisco Public
26
Lazy Update and MCLT

Safe Failover does not require the server to update partner before responding
However what if this update fails to happen because the server goes down?
Partner has no record of lease or lease extension
How does partner know when it is safe to (re)use the lease?
MCLT maximum client lead time

Limits the time in advance of what the partner knows for any lease time assignments/extensions
As MCLT time is usually short (60 minutes), how do clients get long lease times?
BRKNMS-2640
Cisco Public
27
Lazy Update Message Traffic

1. DHCPDISCOVER 2. DHCPOFFER
(Within a short time)
3. DHCPREQUEST 4. DHCPACK Lease time = MCLT =Y

(About 30 minutes later)
5. DHCPBNDUPD Lease Time = X+(Y/2) 24+(1/2) hours = 24.5 6. DHCPBNDACK
Backup
(Within a short time)
Main
9. DHCPBNDUPD Lease Time = X+(X/2) 24+(24/2) hours = 36 10. DHCPBNDACK
7. DHCPREQUEST 8. DHCPACK Lease time = X
Client
X = Desired Client Lease Time (Option 51) Assumed to be 24 hours Y = Maximum Client Lead Time Assumed to be 1 hour /2 = Client renewal time is 50% of lease time
Cisco Public
BRKNMS-2640
28

DHCP Scale Considerations
DHCP Reliability Considerations IPv6 and DHCP

IPv6 Introduction
Functionally similar to IPv4
Connectionless network-layer protocol Used by transport protocols (TCP and UDP) Runs over all possible hardware technologies
But:
Larger addresses
Completely new datagram header format Fewer fields in header Option headers follow main header
BRKNMS-2640
Cisco Public
30
IPv4 and IPv6 Header Comparison

IPv4 Header
Version
IPv6 Header
Total Length
Version
IHL
Type of Service
Traffic Class
Payload Length
Flow Label
Next Header Hop Limit
Identification Time to Live Protocol
Flags
Fragment Offset
Header Checksum
Source Address Destination Address
Source Address
20 Bytes
Destination Address
Legend
Fields Name Kept from IPv4 to IPv6
Fields Not Kept in IPv6

Name and Position Changed in IPv6 New Field in IPv6
BRKNMS-2640
40 Bytes
Cisco Public
31
IPv6 Addresses
Divided into two conceptual parts (like IPv4)
Prefix
Globally unique
Assigned to a link Known as link address or link prefix
Suffix
Only unique within a link Assigned to an individual interface Known as interface identifier
BRKNMS-2640
Cisco Public
32
Address Assignment
Manual
DHCPv6
Stateless address auto-configuration; host:
Derives EUI-64 interface identifier from MAC address Constructs address from prefix advertised by router and EUI-64 interface identifier
Performs duplicate address detection to confirm address is not already in use

Prefix from RA: 2001:DB8:3:0::/64
2001:DB8:3:0: 214:51ff:fed9:a45a
MAC Address from Interface: 00:14:51:d9:a4:5a
BRKNMS-2640
Cisco Public
33
Improvements in DHCPv6 over DHCPv4

L3-only transport
Link-local addressing between client and server (or relay agent)
No need for all-zeros IP source address
Assignment of multiple addresses to a client Unique, uniform client identification Explicit lease renewal and lease rebinding messages Larger option code space (16-bit option code)
Most information carried in options (instead of fixed header fields)

Relay agent chaining through message encapsulation Server message to force client reconfiguration
BRKNMS-2640
Cisco Public
34
Motivation for DHCPv6

Doesnt stateless address auto-configuration eliminate the need for DHCPv6? No
Some organizations want to control and monitor the IPv6 addresses in use on the network Stateless provides no means to differentiate hosts Hosts need other information such as addresses of DNS servers, search lists, Routers and home gateways need prefix delegation
BRKNMS-2640 Cisco Public
35
Role of Routers in Host Configuration

Routers are configured with:
Whether to act as default router Prefixes on each link Whether hosts should use DHCPv6 (M/O bits)
Routers send router advertisement messages with list of prefixes and signal for use of DHCPv6
Use as Default Router

Dont Use DHCPv6 Link Prefix 1 Use SLAAC
Link Prefix 2 Use SLAAC
BRKNMS-2640
Cisco Public
36
Theory and Practice of DHCPv6

Similar to DHCPv4
Many details differ

Allows assignment of multiple addresses to one interface
Performs prefix delegation Uses IPv6 addressing modes, including link-local addresses and multicast
Logically independent from DHCPv4

May be implemented in same server process May share interfaces
BRKNMS-2640
Cisco Public
37
DHCPv4/DHCPv6 Coexistence
IETF design decision: DHCPv4 and DHCPv6 are separate protocols
Different message formats Different message exchanges
Separate options
Host runs DHCPv4 and DHCPv6 as separate functions What about options that provide same information in DHCPv4 and DHCPv6; e.g., DNS servers?
BRKNMS-2640
Cisco Public
38
Basic DHCPv6 Message Exchange

Client multicasts SOLICIT message on local subnet Servers send ADVERTISE message with lease information
Server 1 Client Server 2
Client selects lease and multicast REQUEST message

Selected server sends REPLY message
BRKNMS-2640
Cisco Public
39
DHCP Transport over IPv6

DHCPv6 uses Layer 3 delivery by using link-local addresses Client transmits messages with:
Layer 3: All_DHCP_Relay_Agents_ and_Servers dest interface link-local source
Client
Server
L3 dst=FF02::1:2 src=FE80::214:51ff:fed9:a45a
Server responds with:

Layer 3: client link-local dest server link-local source
L3 dst=FE80::214:51ff:fed9:a45a src=FE80::214:51ff:fe65:7413
BRKNMS-2640
Cisco Public
40
Stateless DHCPv6
Used in conjunction with stateless address autoconfiguration
DHCPv6 server does not need to retain state for each client; e.g., assigned addresses, lease state Client uses stateless DHCPv6 (RFC 3736) to obtain configuration information Very simple protocol server; can be easily deployed in routers rather than as centralized service
BRKNMS-2640
Cisco Public
41
IPv6 Deployment Model for SOHO

IPv6 has enough prefixes to assign a prefix to every service provider subscriber or branch office
Subscriber network will have IPv6 router (instead of computer or NAT) connected to service provider
DHCPv6 prefix delegation informs subscriber router of prefix to use
Assignment of a prefix to a subscriber or an organization, rather than a single address, is recommended for IPv6 IPv6 prefix delegation uses DHCPv6 to provision a router with the prefix to be used at that site Site router then assigns /64 prefixes from delegated prefix to each link in the site network
BRKNMS-2640
Cisco Public
42
Home IPv6 Network Model (Cable)

BAC
Servers
DHCP, DNS
CNR CNR
BAC
Home Network
Customer Admin Domain Service Provider Admin Domain
TFTP
TOD
Management
Wireless Access Point CM Router

Ethernet Bridge ZigBee
HFC CMTS Router
Core
To Internet
CM Router initiates DHCPv6 after receiving RA

Receives IPv6 address for HFC link Receives 2001:DB8:0:30::/60 (prefix delegation) Receives list of DNS servers and other configuration CM Router must have stateful firewall
CM Router assigns /64 prefixes from 2001:DB8:0:30::/60 to customer network links
HFC Link: Assigned 2001:DB8:FFFF:0::/64 (mgmt) and 2001:DB8:FFFE:0::/64 (Service) Customer Home Network Link 0 (Wireless): Assigned 2001:DB8:0:30::/64 Customer Home Network Link 1 (Bridged): Assigned 2001:DB8:0:31::/64 Customer Home Network Link 2 (ZigBee): Assigned 2001:DB8:0:32::/64
BRKNMS-2640
Cisco Public
43
IPv6 Deployment Model for Branch Office

IPv6 prefix can be assigned to enterprise branch office
Branch office gateway router provides IPv6 service to branch office network DHCPv6 prefix delegation informs branch office router of prefix to use Branch office router assigns /64 prefixes from delegated prefix to each branch office network link
Add interface index to /48 prefix to generate /64 for each link Delegated prefix 2001:DB8:3::/48 and assign prefix 2001:DB8:3:1::/64 to interface 1
BRKNMS-2640
Cisco Public
44
Branch Office IPv6 Network Model

Servers
Branch Office Network
DHCP
DNS
Management
Branch Router
Core
Router
Branch Router initiates DHCPv6 Receives IPv6 address for enterprise net link Receives 2001:DB8:3::/48 (prefix delegation) Receives list of DNS servers and other configuration Branch Router assigns /64 prefixes from 2001:DB8:3::/48 to branch office network links Enterprise Network Link: Branch Office Link 0 (Wireless): Branch Office Link 1 (Desktop): Branch Office Link 2 (Data Center):
BRKNMS-2640
Assigned 2001:DB8:FFFF:0::/64 Assigned 2001:DB8:3:0::/64 Assigned 2001:DB8:3:1::/64 Assigned 2001:DB8:3:2::/64

Cisco Public
45
Routing and DHCPv6 Prefix Delegation

Prefix delegation requires routing updates in delegating router and requesting router
Injection of routing information for delegated prefix Determination of default router
DHCPv6 snooping typically used DHCPv6 leasequery (RFC 5007 and 5460) allows requesting router to obtain information about delegated prefixes from DHCPv6 server
BRKNMS-2640
Cisco Public
46

DNS Deployment DNS Service Security
Names
. com.
com (root)
org
edu
example.com.
example purdue
bucknell
www.example.com.
www
cs
BRKNMS-2640
Cisco Public
48
The Domain Name System (DNS)

DNS is a distributed database, with distributed administration and responsibility
The database key is a Fully Qualified Domain Name (FQDN) that consists of a string of tokens separated by .
Example : www.cisco.com
The data is stored in Resource Records (RR) of which there are many types, examples are A, AAAA, PTR and MX.
Product of the IETF to replace original HOSTS.TXT file
BRKNMS-2640
Cisco Public
49
DNS Features
The DNS is designed for look-up queries
The DNS holds two major types of information

The actual data available as answers to queries Structural information for DNS itself
Information is logically grouped in zones; a zone is the unit of control, modification rights and replication operations apply to zones
BRKNMS-2640
Cisco Public
50
Data in the DNS Namespace Database

Each FQDN in the namespace has one or more RRs containing the data associated with the FQDN
A RR consists of a left- and right-hand side

Left hand side = FQDN/owner (lookup key)
Right hand side = type of record and data FQDN TTL CLASS TYPE VALUE
www.example.com. www.example.com.
1800 1800
IN IN
AAAA A
2001:DB8:1:1::22 192.168.50.22
Many RR types: MX, CNAME, PTR
BRKNMS-2640
Cisco Public
51
Queries
Lookup is based on FQDN, class, and type
example.com.
IN
Query for example.com

example.com.
4711
IN
192.168.1.1
BRKNMS-2640
Cisco Public
52
DNS is a Universal Lookup Service

Lookup by name to find IPv4 address(es)
www.l.google.com: type A, class IN, addr 64.233.169.147

xn--9n2bp8q.xn--9t4b11yi5a : type A, class IN, addr 199.7.85.16
Lookup by name to find IPv6 address(es)

ipv6.l.google.com: type AAAA, class IN, addr 2001:4860:b004::68
Lookup by name to find mail server(s)

cisco.com: type MX, class IN, preference 10, mx sj-inbound-b.cisco.com
cisco.com: type MX, class IN, preference 15, mx rtp-mx-01.cisco.com
cisco.com: type MX, class IN, preference 25, mx syd-inbound-a.cisco.com
Lookup by IPv4 address to find domain name

25.219.133.198.in-addr.arpa: type PTR, class IN, www9.cisco.com
BRKNMS-2640
Cisco Public
53

Lookup by service to find host and port
_sip._tcp.example.com: type SRV, class IN, priority 0, weight 10, port 5060, host sip.example.com
Lookup by name to find services

example.com: type NAPTR, class IN,
example.com: type NAPTR, class IN, example.com: type NAPTR, class IN,
1 1 "s" "" "" _sip._tcp.example.com

1 1 "s" "" "" _clip._tcp.example.com 1 1 "s" "" "" _wins._tcp.example.com
Lookup by E.164 number to find URL or URN

5.4.3.2.1.e164.arpa.: type NAPTR, class IN, 1 1 "u" "E2U+sip" "!.*!sip:joe@example.com!" .
BRKNMS-2640
Cisco Public
54

Lookup by name to find the real name of the address
www.google.com: type CNAME, class IN, cname www.l.google.com www.l.google.com: type A, class IN, addr 64.233.169.103 www.l.google.com: type A, class IN, addr 64.233.169.104
ipv6.google.com: type CNAME, class IN, cname ipv6.l.google.com ipv6.l.google.com: type AAAA, class IN, addr 2001:4860:b004::68
Lookup by zone name to find name server

cisco.com: type NS, class IN, ns ns1.cisco.com
cisco.com: type NS, class IN, ns ns2.cisco.com
Lookup by zone name to find Start of Authority

cisco.com: type SOA, class IN, mname dns-rtp2-3-l.cisco.com
BRKNMS-2640
Cisco Public
55
Reverse Zone
PTR records used to resolve name for an IP address
Canonical representation of IP address used as FQDN

IPv4reversed dotted decimal concatenated with IN-ADDR.ARPA. (for address 192.168.50.22)
22.50.168.192.in-addr.arpa 1800 IN PTR www.example.com
IPv6reversed dotted hexadecimal nibbles concatenated with IP6.ARPA. (for address 2001:db8:1:1::22)
2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 1800 IN PTR www.example.com
Zone delegations based on address-FQDN components; gets tricky when delegations are not on FQDN component boundaries
BRKNMS-2640
Cisco Public
56
Internationalized Domain Names (IDN)

According to Global Reach at www.glreach.com
60 percent of Internet users are non-English speakers, while the dominant language used on the Internet is English Enter the URL http://.
This is example.test in Korean Hangul script result = query for xn--9n2bp8q.xn--9t4b11yi5a
See also RFC 3490
BRKNMS-2640
Cisco Public
57
IDN
http:// . example.test in Arabic script
BRKNMS-2640
Cisco Public
58
Domains and Zones

All nodes below a node are included in the same domain
Nodes are grouped in administrative zones
Each node can be the start of a new zone, but it doesnt have to be A node which is the start of a new zone is called a delegation point
com com-zone
purdue
root-zone
org
edu
example example.com-zone
bucknell
www
cs
purdue.edu-zone
com-domain
Domain Zone
BRKNMS-2640
Cisco Public
59
A DNS Server performs two functions

Hosts must be able to query FQDNs of the entire DNS namespace
Recursive servers provide resolution service Hosts and recursive servers must be able to issue DNS queries about zones you administer Authoritative servers respond to queries for FQDNs under their authority DNS Database
FQDN Resolution Application Stub Resolver Internet Root Server
com Name Server

example Name Server
Recursive Server
BRKNMS-2640
Cisco Public
60
DNS Name Resolution

www.widgets.example.com ?
DNS Database Root Server
1.2.3.4
Application 1 5 Stub Resolver

2
com Name Server

Internet example Name Server
Recursive Server
Widgets Name Server
1. An application wants to resolve www.widgets.example.com into an IP address

2. Stub Resolver code (typically in a library on the host where the application runs) sends a DNS protocol request message to (local) recursive server 3. Recursive server sends DNS protocol request messages to many DNS name servers; the recursive server may cache the answers
4. Recursive server returns IP address to stub resolver through a DNS protocol message
5. Stub resolver communicates IP address to application
BRKNMS-2640
Cisco Public
61
Recursive Resolution
www.widgets.example.com ? NS for com = a, b, c
DNS Database Root Server
com Name Server example.com Name Server
NS for example.com = x, y
NS for widgets.example.com = m, n
www.widgets.example.com = 1.2.3.4
Widgets.example.com Name Server
1. Question = resolve www.widgets.example.com In the DNS protocol the question will always be the same. 2. Ask root server(s) (known via hint list); they will only answer which server(s) know com. which is likely a top level domain (TLD)
3. Ask server(s) for com.; they return a NS list that know about example.com.
4. Ask server(s) for example.com.; dependent on how the zones are laid out they might return the answer for www.widgets.example.com or else return a NS list that know about widget.example.com. 5. Finally the widget.example.com name server returns the answer
BRKNMS-2640
Cisco Public
62
Resolution Details
Recursive server provides complete resolution
Recursive server follows pointers to contact next name server to work its way through the components from right to left
Delegation = name servers return pointers to next name server(s)
Optimization through caching

Recursive servers cache results of name resolution Subsequent requests are resolved through local cache
Authoritative servers control time of caching through TTL Negative caching (saving information about non-existent records) is required by RFC 2308
BRKNMS-2640
Cisco Public
63

DNS Deployment What Where Why?
DNS Service Security
Deploying Authoritative Servers

Use a hidden primary or gold master
It will make authorization of changes easier
Slave servers answer all requests authoritatively, they obtain info only from the master
Close to your own hosts In your DMZ, reachable from outside
At least one slave somewhere else on the Internet

This gives responses when your own slaves are not reachable
BRKNMS-2640
Cisco Public
65
Detailed Network [Enterprise] Layout

192.168.17.53
192.168.1.2 Internal Cache = Recursive Router D + firewall + NAT Router C + firewall 192.168.33.3 Router A
Internet
Hidden Master = Authoritative
1.168.51.15
Internal Slave = Authoritative
192.168.2.2
DMZ Slave = Authoritative
Router B
192.168.3.5
Internal Cache = Recursive
External Slave = Authoritative

192.168.33.4-6 DMZ Cache = Recursive
Internal
BRKNMS-2640
DMZ
Cisco Public
External
66
Queries from the Inside

Internet
Hidden Master = Authoritative

DMZ Cache = Recursive
Internal
BRKNMS-2640
DMZ
Cisco Public
External
67
Zone Transfers Update the Slaves

Hidden Master = Authoritative Internal Cache = Recursive
Internet

DMZ Cache = Recursive
Internal
BRKNMS-2640
DMZ
Cisco Public
External
68
Queries from the Outside
Internet
Internal
BRKNMS-2640
DMZ
Cisco Public
External
69
Queries from Subscribers
Internet
Access
Network
Internal
BRKNMS-2640
DMZ
Cisco Public
External
70

Security Exposures in DNS

Root Server com Server example Name Server (Database)
1
example Name Server (Master) example Name Server (Slave)
FQDN Resolution Application

Stub Resolver 3 4 Internet
2 Recursive Server
widgets Name Server
1. Corruption of name server database: DDNS, admin spoofing
2. False zone transfers 3. Spoofed responses to recursive server queries 4. Spoofed responses to stub resolver queries
BRKNMS-2640
Cisco Public
72
TSIG, SIG(0), and DNSSEC

TSIG: uses shared secret key to protect DNS transactions
Sender computes hash of transaction using secret key Received confirms integrity using secret key
SIG(0): uses public/private key pair to protect DNS queries

Sender computes signature of transaction using private key of public/private key pair Receiver confirms authenticity using public key
DNSSEC: uses signed RRset to protect DNS data

Sender computes signature of RRset using private key of public/private key pair Receiver confirms authenticity using public key
BRKNMS-2640
Cisco Public
74
Securing Database Updates

Administrative security policies and mechanisms dont let the bad guys access the database
TSIG between DNS components that are part of same administrative organization and that can share a private key
Zone transfers Resolution requests/responses between stub resolver and recursive server
BRKNMS-2640
Cisco Public
75
DNSSEC Detects Spoofed Responses

DNSSEC used to prove response comes from zone owner Zone owner adds to the RRset a RRSIG containing signature using private key of public/private key pair for that zone
A Resolver That Trusts This Public Key
Key for example.com www.example.com Has Address Signature

Can Use This Signature
Resolver authenticates signature using matching public key RRset with signatures can be forwarded and cached
to Verify This Data

Cisco Public
BRKNMS-2640
76
ButHow Does the Resolver Get the Key for example.com?

Three new RR types used to store cryptographic data
DNSKEYholds public key
Key for com

example.com Key Has Signature Signature
DSholds public key hash for a subzone

RRSIGholds RRset signature
(There are 3 other RRs: NSEC, NSEC3, NSEC3PARAM)
Hash of public key for example.com is stored in a DS RR in the com zone; public key is stored in a DNSKEY RR in the example.com zone
Resolver with public key for com
Uses public key for com to authenticate signature of DS RR for example.com Retrieves public key for example.com in DNSKEY RR from example.com zone and authenticates with DS RR Resolves www.example.com and authenticates RR(s) with key from example.com DNSKEY RR
Key for example.com
Signature
www.example.com Has Address Signature
BRKNMS-2640
Cisco Public
77
Global view of signatures and keys

FQDN com. zone CL TYPE RDATA
com.
example.com
IN
IN
DNSKEY
RRSIG DS
xyz23Cryryptogrm4d3DS
Signature of DS Hash for public key of example.com
example.com. zone
example.com
IN
DNSKEY
A RRSIG
3245sdFD56G4ggf15R5
64.64.64.64 Signature for RR
www.example.com IN
means used to validate
means authentified by
BRKNMS-2640
Cisco Public
78
Why Arent We Using DNSSEC Today?

Requires chain of signed zones
Root TLDs organizations Trust islands may be an interim step
Processes for key and trust anchor management and rollover need to be worked out
Organizations need to get keying information into TLDs RFC 5011 mechanisms need to be deployed for trust anchors
Applications are unprepared for DNSSEC

How does an application react to an unsecured response or a response that fails authentication?
Organizations need to deploy DNSSEC

Name servers; recursive servers with a mechanism for securing DNS traffic between hosts and recursive servers
Root zone has been signed since July 15, 2010 Good information source - http://www.dnssec-deployment.org/
BRKNMS-2640
Cisco Public
79
Trust Island for DNSSEC

Root Zone
Example.com Zone Public Key Resolver com Zone
example.com Zone
Resolver can be configured with public key for example.com zone Resolver performs unsecured resolution through root and com zones
Then, resolver applies example.com zone key for secure resolution of example.com zone
BRKNMS-2640 Cisco Public
80
Dynamic Host Configuration Protocol DHCP Domain Name System DNS Interaction Between DNS and DHCP
DNS Namespace and IP Addressing

DNS namespace and IP addressing architecture are fundamentally orthogonal
Name hierarchy need not follow network topology; two devices on the same link may use different domain names Address assignment must follow network topology, so an address assigned to a device must come from a prefix assigned to the link
but name and address management interact in several ways

IP addresses in PTR records
Configuration of host to know DNS servers (evaluation order) Configuration of host for evaluation order
Reverse delegationDelegation of IP addresses implies delegation of zone authority
BRKNMS-2640
Cisco Public
82
Address Assignment and DNS

RRset(s) for a device must be updated with address(es) assigned to the device
IP addresses in A/AAAA RRs for the devices FQDN must reflect the IP addresses assigned to the host
Static: simultaneously add entries to DHCP and DNS services
Automatic: simultaneously add entries when address is first assigned
Dynamic: add entries when address is first assigned; update RRs if address changes; delete RRs if lease expires
BRKNMS-2640
Cisco Public
83
Getting New IP Addresses into DNS

Update DNS server database manually
Edit configuration file Through a GUI
(Dynamic) DNS Update (DDNS) from host

Host sends DNS Update when new address is assigned
What name to use/allow?
Update both forward and reverse?
Authentication and authorization requires trust relationship with each host; does this scale?
What if the DHCP address lease expires?
BRKNMS-2640
Cisco Public
84
Getting New IP Addresses into DNS

DHCP Client bvolz.widgets.example.com DHCP Service
DHCP Client
DHCP Relay Agent
Organization Network
DHCP Server
DNS update for bvolz.widgets.example.com
DNS Database Root Server com Name Server example Name Server widgets Name Server
DNS update from DHCP server

DHCP and DNS servers must have a trust relationship; fewer components to secure Can purge expired address
Requires explicit collaboration if DHCP and DNS servers are in different admin domains
Only works for addresses assigned through DHCP
BRKNMS-2640
Cisco Public
85
Why Use DNS Update?

Mobility is easier
Laptops are not the only devices that uses IP addresses and need domain names
Platform and proprietary solutions have existed, but a standardized version was missing
Fast, secure updates of the DNS are required

DNS Update provides mechanism in DNS to update RRs
Can be secured (i.e., TSIG) Used by host (with appropriate trust and security) Used by DHCP server (for reverse and perhaps forward)
BRKNMS-2640
Cisco Public
86
Update of PTR Record

PTR records should be updated at same time as A (and AAAA) when addresses are changed
If addresses are assigned through DHCP, the network admin owns the address (reverse zone) and should have the DHCP server do the update
DHCP server can learn host FQDN through DHCP options or can enforce its own naming policy
If clients name used, assumes implicit trust relationship between host and DHCP server - host is authorized to use name Explicit authentication of host identity and authorization of host to use name and authentication of DHCP message exchange is an unsolved problem
BRKNMS-2640
Cisco Public
87
Cisco IOS DHCP Client and Server Running DDNS

DHCP Client router.widgets.example.com DHCP Server
Organization Network
DHCP Service
DHCP Client
The Cisco IOS DHCP client can perform DNS* or HTTP updates and use client FQDN option to communicate choice to the DHCP server The Cisco IOS DHCP server can perform DNS* or HTTP updates and uses or override client preference
DNS Root Server
Database
com Name Server example Server
Name
widgets Name Server *RFC 4702 DHCP client FQDN option

BRKNMS-2640
Cisco Public
88
Configuration of Host for DNS

Obtaining pointers to DNS service is almost as important to host operation as obtaining an IP address
DHCP service can be (and usually is) configured to pass information about DNS to the DHCP client via DHCP options
Addresses of recursive servers
List of domain names for FQDN resolution
BRKNMS-2640
Cisco Public
89


NMS sessions offered (1 of 2)

Session
Monday: Introduction to Network Performance Measurement with Cisco IOS BRKNMS-1204 IP Service Level Agent BRKNMS-2032 Rapid and Repeatable Service Delivery Through Automation
Title
BRKNMS-3021 Advanced Cisco IOS Device Instrumentation Tuesday:

BRKNMS-1032 Network Management KPI's BRKNMS-1532 Introduction to Accounting Principles with NetFlow and NBAR
BRKNMS-2010 Using a Network Hypervisor to Build Public and Private Clouds BRKNMS-2031 SYSLOG Design, Methodology and Best Practices BRKNMS-2035 Ten Cool LMS Tricks to Better Manage Your Network
BRKNMS-2501 Enterprise QoS Deployment, Monitoring and Management
BRKNMS-2640
Cisco Public
91
NMS sessions offered (2 of 2)

Session Wednesday:
BRKNMS-2031 SYSLOG Design, Methodology and Best Practices
Title
BRKNMS-1942 Managing Infrastructure as a Service (IaaS) for Cloud Environment

BRKNMS-2499 Operating and Managing Converged Enterprise Architectures Advanced Performance Measurement for Critical IP Traffic with BRKNMS-3043 Cisco IOS IP Service Level Agreements BRKNMS-3132 Advanced NetFlow Thursday: BRKNMS-2006 Energy Management BRKNMS-2030 Onboard Automation with Cisco IOS Embedded Event Manager BRKNMS-2640 Advanced DHCP and DNS Deployments BRKNMS-2658 Securely Managing Your Networks and SNMPv3
BRKNMS-1035 The NOC at CiscoLive

BRKNMS-2640
Cisco Public
92
Complete Your Online Session Evaluation

Receive 25 Cisco Preferred Access points for each session evaluation you complete. Give us your feedback and you could win fabulous prizes. Points are calculated on a daily basis. Winners will be notified by email after July 22nd.
Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.
Dont forget to activate your Cisco Live and Networkers Virtual account for access to all session materials, communities, and on-demand and live activities throughout the year. Activate your account at any internet station or visit www.ciscolivevirtual.com.
BRKNMS-2640
Cisco Public
93
Recommended Reading
The DHCP Handbook

Ralph Droms and Ted Lemon. Sams Publishing, 2002. ISBN: 978-0-672-32327-3
Available Onsite at the Cisco Company Store

BRKNMS-2640
Cisco Public
94
Recommended Reading
DNS and BIND

by Cricket Liu & Paul Albitz OReilly ISBN: 978-0-596-10057-5
Available Onsite at the Cisco Company Store

BRKNMS-2640
Cisco Public
95
Recommended Reading
IP Address Management Principles and Practice

by Timothy Rooney ISBN 978-0-470-58587-0
Introduction to IP Address Management

by Timothy Rooney ISBN 978-0-470-58588-7
BRKNMS-2640
Cisco Public
96
Thank you.
BRKNMS-2640
Cisco Public
97
Appendix A:
Terminology, Acronyms, References
Terminology
Class DDNS DHCP Server A field in a DNS Resource Record that class field specifies the protocol group (usually IN for Internet) A method for dynamic updates to DNS data through DNS messages Responds to DHCP messages; manages IP address assignment and reclamation; assigns configuration information to hosts Initiates DHCP message exchanges; implemented on a host to obtain an IP address and other configuration information for the host A function of a network element like a router, that forwards DHCP messages between clients and servers and eventually modifies the messages Prefix delegation for DHCPv6; an extension to DHCPv6 that allows a DHCPv6 server to delegate prefixes to other DHCPv6 servers thus forming a delegation hierarchy A method for securing DNS RRs using public/private keys and a trust chain to authenticate the public key
DHCP Client
DHCP Relay Agent
DHCPv6 PD
DNSSEC
BRKNMS-2640
Cisco Public
99
Terminology
Domain A subtree of the global DNS name space. Often used to refer to an organizations subtree, e.g., the MIT domain, the ISI.EDU domain, the root domain Updates to the DNS protocol, expanding several fields and allowing for longer UDP messages (RFC 2671) Fully qualified domain name; the name of a node in the DNS name space A communication facility or medium over which nodes can communicate at the link layer (RFC 2460) A program that holds DNS data and answers queries On Demand Address Pools; an extension to DHCPv4 that allows DHCP servers to assign and recover addresses in address pools A bit string that consists of some number of initial bits of an address (RFC 2461) A program that accepts a DNS resolution request from a host and exchanges DNS protocol messages to complete the name resolution
EDNS0 FQDN Link Name Server ODAP
Prefix Recursive Server
BRKNMS-2640
Cisco Public
100
Terminology
Resolver A program that accepts DNS resolution requests from an application and initiates a DNS protocol message exchange The name servers for the root of the DNS name space Resource Record; the atomic unit of information in the domain system A set of all RRs associated with an FQDN and type A method for securing DNS message exchanges using public/private keys (not in common use) Top level domain; e.g., .com, .edu, .org, .uk A method for securing DNS message exchanges using a shared secret or GSS-API Time-to-Live A field in a DNS Resource Record that specifies how long a domain resolver should cache the RR before it throws it out and asks a domain server again A zone is a portion of the DNS name space that is managed as a unit
Root Server RR
RRset SIG(0) TLD TSIG
TTL
Zone
BRKNMS-2640
Cisco Public
101
DNS and the IETF

DNS is a product of the IETF; specifications are published in RFCs
Original specification: RFC 1034, RFC 1035 DNS dynamic updates (DDNS): RFC 2136
EDNS0: RFC 2671 DNS security

DNSSEC: RFC 4033, RFC 4034, RFC 4035, RFC 5155 SIG(0): RFC 2931 TSIG: RFC 2845
DNS extensions (dnsext) working group of the IETF continues to develop extensions to DNS
DNS operations (dnsop) working group develops guidelines for the operation of DNS software servers and the administration of DNS zones
BRKNMS-2640
Cisco Public
102
IETF Standards related to DNS

RFC 974 (2821, 5321), 1034, 1035
RFC 1995 (Incremental Zone Transfer) RFC 1996 (Notify)

RFC 2136 (Dynamic Update) RFC 2782 (SRV Records) RFC 2308 (Neg. Caching)
RFC 2317 (Classless in-addr.arpa) RFC 2181(DNS Clarification) RFC 2845 (Secret Key Transaction Authentication)
RFC 2915 (NAPTR) RFC 3152 (Delegation of ip6.arpa) RFC 3363 (Representing IPv6 Addr in DNS)
BRKNMS-2640
Cisco Public
103
DHCP and the IETF

DHCP is a product of the IETF; specifications are published in RFCs
Work on DHCP began in 1990 Current specification published in 1997 as RFC 2131 and RFC 2132
Based on earlier protocol, BOOTP
Dynamic Host Configuration (DHC) working group of the IETF continue to develop extensions to DHCP
New options for services, location information, relay agents
DHCP for IPv6 (published as RFC 3315 in 2003)
BRKNMS-2640
Cisco Public
104
Significant Extensions
Relay agent options (RFC 3046)
DHCP message authentication (RFC 3318, RFC 4030) DHCP for IPv6 (RFC 3315) and DHCPv6 prefix delegation (RFC 3633) Many new options, redefinition of option code space to allow for more DHCP options
BRKNMS-2640
Cisco Public
105
IETF Standards
RFC 951 (Bootstrap Protocol) RFC 1048, 1395, 1497, 1542, 2132 (BOOTP Vendor Info) RFC 1534 (Interoperation Between DHCP and BOOTP)
RFC 2131 (Dynamic Host Configuration Protocol)

RFC 3004 (User Class Option for DHCP) RFC 3011 (IPv4 subnet selection)
RFC 3046 (DHCP Relay Agent Information Option)

RFC 3074 (DHCP Load Balancing) RFC 3256 (The DOCSIS Device Class DHCP Relay Agent Information Suboption)
RFC 3442 (The Classless Static Route Option for Dynamic Host Configuration Protocol [DHCPv4]) RFC 3495 (Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client)
RFC 3527 (Link Selection Suboption for the Relay Agent Information Option for DHCPv4) RFC 3594 (PacketCable Security Ticket Control Suboption for the DHCP CableLabs Client Config [CCC]) RFC 3315, 3633, 3736 (DHCP for IPv6, Prefix option, Stateless DHCP for IPv6)
BRKNMS-2640
Cisco Public
106
Appendix B: DHCP as an IP address management system
IPv4 Address Management

IPv4 address plan
Start with network link topology Estimate hosts on each link Pick IPv4 prefix length (subnet mask) to accommodate expected hosts
Assign IPv4 prefixes for aggregation
Can split a prefix later when new links are added
BRKNMS-2640
Cisco Public
108
Sources of Information About Networks

Network management tools should contain IP addresses in use, observed or planned
Router configurations provide

Interfaces for link topology Assigned networks and subnet masks
Can be obtained with grep from Cisco IOS

egrep ^[ \t]ip address *-confg |grep 255\.255
Can be queried using SNMP

snmpwalk {options} mib-2.ip.ipAddrTable
BRKNMS-2640
Cisco Public
109
How Do You Count the Number Of Devices?

00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 0f:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:e1:2e:8b:12:aa 00:fa:66:ec:2e:8b:12:aa 00:fa:66:3c:2e:8b:12:aa
00:fa:16:e1:2e:8b:12:aa
00:fa:66:e1:2b:8b:12:aa
00:fa:66:ee:2e:8b:12:aa
f0:fa:66:e1:2e:8b:12:aa
00:fa:88:e1:2e:8b:22:aa
00:fa:61:e1:2e:8b:12:aa
00:fa:66:e1:2e:8b:52:aa
00:fa:66:e1:2e:8b:12:9a 00:fa:66:e1:2e:8b:12:ea
BRKNMS-2640
Cisco Public
110
Host Address Management

Address assignment
Manual Static, automatic, dynamic => DHCP Auto-configuration
DHCP service has to choose address from right prefix

Address plan configured into DHCP server DHCP server identifies subnet to which client is attached from giaddr and chooses an address from the prefix for that link DHCP server uses Option 82 to identify last mile copper pair and decides subnet for customer
BRKNMS-2640
Cisco Public
111
Appendix C: DHCP Class of Service
Examples of Class of Service

Address leasesHow long a set of clients should keep its addresses
IP address rangesFrom which lease pool to assign clients addresses, example: walled garden DNS server addressesWhere clients should direct their DNS queries DNS hostnamesWhat name to assign clients Denial of serviceWhether unauthorized clients should be offered leases
BRKNMS-2640
Cisco Public
113
How the Client Is Classified

MAC address
Link (=subnet) to which client is attached

Port to which client is attached Device type: PC, IP phone, cable modem Device status: unauthenticated/authenticated
BRKNMS-2640
Cisco Public
114
DHCP Relay: Centralized DHCP Service

DHCP client broadcasts a DHCPDISCOVER packet Relay agent on the router receives the message, fills in the giaddr field with IP address of the receiving interface of router, and forwards it to the server DHCP relay agent forwards (unicasts) the packet to multiple DHCP server ; client will choose the best DHCPOFFER
Relay Agent IP Address 192.168.50.1 DHCP Server 192.168.200.8
Relay Agent IP Address 192.168.2.1

Network Prefix 192.168.2.0/24
Organization network
DHCP Packet
GIADDR
Relay Agent IP Address 192.168.1.1
Network Prefix 192.168.1.0/24
DHCP server uses giaddr field of DHCP packet as an index into the network topology and selects an address from 192.168.1.0/24
DHCP Client
BRKNMS-2640
Cisco Public
115
Relay Agent Options

Relay agent can attach additional information to DHCP message in relay agent options Originally defined in RFC 3046 for cable broadband
Option encodes information about source of DHCPDISCOVER or DHCPREQUEST MESSAGE
Server returns options back to relay agent, which uses information to forward message to cable modem client
Additional relay agent options encode information such as DOCSIS device class, subnet for address assignment
BRKNMS-2640
Cisco Public
116
DHCP Relay Options
DHCP Request
Option 82
DHCP Server 192.168.1.5
DHCP Server 192.168.2.5
DHCP Request
DHCP Request
GIADDR Option 82
DHCP Client
BRKNMS-2640
Cisco Public
117
BRKNMS-2640
Cisco Public
118
Visit the Cisco Store for Related Titles http://theciscostores.com
Thank you.
BRKNMS-2640
Cisco Public
120

Advanced DHCP and DNS Deployments

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Advanced DHCP and DNS Deployments

Загружено:

Авторское право:

Доступные форматы

Advanced DHCP and DNS Deployments

2011 Cisco and/or its affiliates. All rights reserved.

2011 Cisco and/or its affiliates. All rights reserved.

Meet the Engineer

2011 Cisco and/or its affiliates. All rights reserved.

What You Will Learn

2011 Cisco and/or its affiliates. All rights reserved.

Dynamic Host Configuration Protocol DHCP

Domain Name System DNS

Managing the DHCP Server

Server configured with:

Network administrator controls DHCP service

Which hosts to serve

2011 Cisco and/or its affiliates. All rights reserved.

DHCP Leases Network Configuration

Send My Configuration Information

DHCP delivers other configuration information in options

Basic DHCP Message Exchange

Selected server sends DHCPACK message

2011 Cisco and/or its affiliates. All rights reserved.

Refresh Lease Sequence

Selected server sends DHCPACK message, extending the lease.

2011 Cisco and/or its affiliates. All rights reserved.

Dynamic Host Configuration Protocol DHCP

Domain Name System DNS

Architectures for DHCP Service (1)

DHCP Relay Agent

Pro: Reliability Through redundancy

Pro: Centralized Management

DHCP Relay Agent

2011 Cisco and/or its affiliates. All rights reserved.

The Cisco IOS DHCP Server at Work

Static DHCP client : per port or per Client-id or MAC address

2011 Cisco and/or its affiliates. All rights reserved.

Architectures for DHCP Service (2)

Redundant DHCP Service

DHCP Relay Agent

DHCP Relay Agents

DHCP Relay Agent

Pro: Independent Operation of Remote Site if WAN Link Fails

Pro: Reliability Through Redundancy with Failover

Best of Both Worlds

DHCP Relay Agents

2011 Cisco and/or its affiliates. All rights reserved.

IPv4 has limited addresses in each subnet

DHCP extensions for dynamic pool assignment

2011 Cisco and/or its affiliates. All rights reserved.

For Millions of Subscribers

DHCP Relay Agent

DHCP Relay Agent IOS Slave Servers

2011 Cisco and/or its affiliates. All rights reserved.

Cisco Network Registrar

Extensible and Customizable

Backup Cluster Local Cluster

Backup Cluster Local Cluster

Dynamic Host Configuration Protocol DHCP

IPv6 and DHCP

Domain Name System DNS

Reliable DHCP Service

2011 Cisco and/or its affiliates. All rights reserved.

But Independent Servers have Issues

If original server is down when client re-connects or during renewal process:

2011 Cisco and/or its affiliates. All rights reserved.

Better if Servers Shared State