runIP 2'1

1
runIP 2.1

• The proven Appliance Solution for VitalQIP
• Rainer MaurerProduct Architect
• n3k Informatik GmbH

2
runIP the proven Appliance for VitalQIP

• runIPTM is an appliance for VitalQIP Remote
  Servers
• turn-key solution (immediate deployment)
• optimized operating system for DNS and DHCP
  servers
• global hardware field support (24/7)
• support for the complete solution (HW, OS,
  VitalQIP, DNS and DHCP services) from one source
• adds additional benefits
• simple distribution of SW updates using a central
  Management Station
• high availability option for (D)DNS
• integrated monitoring

3
Architecture
The VitalQIP environment manages the data used
by the DNS and DHCP servers running on the runIP
Appliance to deliver addresses and name
resolution.
runIP Appliance
VitalQIP EnterpriseServer
DNS / DHCPgeneration
VitalQIP Administrator
DNS / DHCPconfiguration(zone files, scopes,
etc.)
DNS Server DHCP Server VitalQIP
Software Operating System
runIPTMAdministrator
runIPTMManagementStation
(Web Browser)
packageinstall / upgrade
runIPTMSubscriptionServer
runIPpackages
The runIPTM Management Solution manages the
operating system and the versions of the DNS and
DHCP server software executing on the runIP
Appliance. The runIP administrator requests and
downloads runIP packages from the runIP
Subscription Server and pushes them to the runIP
Appliance.
4
runIP version 2.1

• runIP version 2.1 has been available since the
  beginning of August 2006
• new features in runIP 2.1 are highlighted in blue
  in this presentation

5
runIP - Security Features (1)

• security on runIP Appliances
• minimized and hardened operating system
• protected by firewall rules
• only communication to required services is
  allowed
• denied traffic is logged
• second NIC can be set up as external/production
  interface
• e.g. only DNS traffic allowed to external NIC
• support for secure DNSDHCP generation (via SSL)
• support for secure DDNS updates (GSS-TSIG)

6
runIP - Security Features (2)

• security on runIP Management Station / GUI
• communication between appliances and the
  management station is
• protected by the use of ACLs and a shared secret
• encrypted
• via one dedicated TCP port
• auditing of changes (who? when? what?)
• automatic logout from GUI after a certain idle
  time(session timeout)
• authentication callout for the runIP GUI
• targeted administrative rights(privileges based
  on groups of appliances / individual appliances)

7
Admins - Profile
8
Admins - Role
9
Monitoring

• monitoring occuring on each appliance
• monitoring / automatic restart of services
• disk space, CPU utilization, main memory
• monitoring of all configured DNS zones
• monitoring for VitalQIP User Exits
• comprehensive monitoring for HA DNS
• monitoring features in the GUI
• high-level view of the current state for each
  group in the GUI
• can drill-down to find individual error
  conditions on the appliances
• manual check / start / stop of packages
  services
• history of events per group appliance
• User Exit capability on the runIP Management
  Station to forward events to other management
  systems
• n3k provides user exits for sending SNMP traps
  and/or email
• additional monitoring capabilities supported by
  runIP
• SNMP daemon on each appliance (MIB-II, Host
  Resources)
• Lucent SNMP Module

10
Support for VitalQIP Add-On Modules

• VitalQIP Remote Services(any build from 5.2 SP1
  to 6.2)
• VitalQIP SNMP Module
• VitalQIP Audit Manager
• VitalQIP API Toolkit
• VitalQIP Distributed Services
• VitalQIP Services Manager
• VitalQIP DHCP Rules Manager

11
Performance Capacity

• DHCP Performance
• Standard Appliance up to 1,900 leases / s
• High Spec Appliance up to 2,500 leases / s
• DNS Performance
• Standard Appliance up to 32,000 queries / s
• High Spec Appliance up to 50,000 queries / s
• DNS Capacity
• Standard Appliance 1,000,000 RRs, 10,000 zones
• High Spec Appliance 2,000,000 RRs, 20,000 zones

12
runIP a flexible solution

• ability to use runIP Appliances as NTP Servers
• package for configuration of the syslog service
• e.g. redirection to central loghost
• High Availability DNS
• two appliances share a logical name and a logical
  IP address
• when the first appliance doesnt answer DNS
  requests, the second appliance will take over the
  logical IP address within 3 seconds
• user area on appliances (sandbox)
• allows for custom scripts / services
• support for remote management cards
• HW must include DRAC/4 card (old appliances
  dont)
• allow power-cycles, use virtual CDROMs to
  initialize appliances
• IP Anycast for DNS

13
Benefits

• more reliability, less human error, minimal
  service outage
• significantly reduces time to patch upgrade
  remote servers
• ability to perform more frequent upgrades
• IP services team gain control of a critical
  environment
• reduces capital cost for remote servers
• reduced cost of ownership of VitalQIP solution
  by using appliance model. 25 servers/3 yrs 58
• will coexist with current Remote Servers
• replacing servers with runIP Appliances can be
  done gradually, does not have to be all at once

14
Customers

• runIPTM is currently being used by more than 40
  customers
• e.g. British Telecom, Vodafone, American Express,
  RBS, Volkswagen Bank, Marsh, Lufthansa, Europcar,
  Wacker Chemical, CSC, TNT, Bayer, Degussa, Linde
• more than 650 runIP appliances have been deployed
  world-wide on all continents (except Antarctica)

15
IP Anycast for DNS

• Why anycast?
• server load balancing
• service reliability
• client trasparency
• locality / latency improvements
• distributed response to DoS
• IP Anycast is in use successfully for the F DNS
  Root Server on the Internet
• many large corporates have either already
  deployed Anycast for DNS or are looking at it
• How does it work?
• unlike Multicast one node receives each packet
• the node that receives a specific packet is
  determined by routing
• runIP 2.1 will support OSPF, routing daemon
  running on each appliance that has been activated
  for Anycast

16
IP Anycast for DNS - example
runIP HA Pair(Primary, receives all DDNS updates)

central datacenter,WAN hub
queries,zone transfers
runIP withIP Anycast enabled (Secondary or
Caching)
DNS queries automatically re-routed to central
servicewhen local service fails, no local DNS
timeouts
runIP withIP Anycast enabled (Secondary or
Caching)
runIP withIP Anycast enabled (Secondary or
Caching)
individuallocations
DNS queries remain localwhile local DNS service
is up
DNS queries remain localwhile local DNS service
is up
DNS Clients
DNS Clients
17
Questions?