Thứ Bảy, 22 tháng 2, 2014
Tài liệu cisco migrationn_This document describes how to deploy VMware ESX Server 2.5 into the Cisco data center architecture. doc
Corporate Headquarters:
Copyright © 2006 Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Multicast over IPsec VPN Design Guide
This design guide provides detailed configuration examples for implementing IP multicast (IPmc) in a
QoS-enabled IP Security (IPsec) virtual private network (VPN).
Introduction
This design guide addresses implementing IPmc in a QoS-enabled IPsec VPN WAN for both site-to-site
and small office/home office (SOHO).
This design guide is the fourth in a series of Voice and Video Enabled IPsec VPN (V3PN) design guides
that are available under the general link http://ww.cisco.com/go/srnd, which also contains many useful
design guides on QoS, IPmc, and WAN architectures:
• Voice and Video Enabled IPsec VPN (V3PN) Design Guide
• Enterprise Class Teleworker: V3PN for Teleworkers Design Guide
• IPsec VPN Redundancy and Load Sharing Design Guide
IPmc Requirement in Enterprise Networks
IPmc is a means to conserve bandwidth and deliver packets to multiple receivers without adding any
additional burden on the source or receivers of the packets. Applications that deliver their data content
using IPmc include videoconferencing, Cisco IP/TV broadcasts, distribution of files or software
packages, real-time price quotes of securities trading, news, and even video feeds from IP video
surveillance cameras.
The distribution of large data files to all branches by means of a mass update is an efficient way to
distribute parts lists, price sheets, or inventory data. Commercial software packages are available to
optimize this file replication process by using IPmc as the transport mechanism. The corporate server
sends one IPmc stream, and the networked routers replicate these packets so that all remote locations
receive a copy of the file. The software can detect packet loss and at the end of the transfer, request an
IP unicast stream of the missing portions to ensure the file is complete and valid.
6
Multicast over IPsec VPN Design Guide
OL-9028-01
Introduction
IPsec Deployment with Point-to-Point GRE
Generic Routing Encapsulation (GRE) is often deployed with IPsec for several reasons, including the
following:
• IPsec Direct Encapsulation supports unicast IP only. If network layer protocols other than IP are to
be supported, an IP encapsulation method must be chosen so that those protocols can be transported
in IP packets.
• IPmc is not supported with IPsec Direct Encapsulation. IPsec was created to be a security protocol
between two and only two devices, so a service such as multicast is problematic. An IPsec peer
encrypts a packet so that only one other IPsec peer can successfully perform the de-encryption. IPmc
is not compatible with this mode of operation.
Until the introduction of IPsec Virtual Tunnel Interface (VTI), IPsec tunnels were not logical tunnel
interfaces for routing purposes. A point-to-point (p2p) GRE tunnel, on the other hand, is a logical router
interface for purposes of forwarding IP (or any other network protocol) traffic. A tunnel interface can
appear as a next-hop interface in the routing table.
Virtual Tunnel Interface
VTI is introduced in Cisco IOS Release 12.3(14)T. A tunnel interface with the new Cisco IOS interface
tunnel mode ipsec ipv4 command along with the previously introduced tunnel protection interface
command enables the VTI feature.
Note Tunnel protection alleviates the need to apply crypto maps to the outside interface.
VTI provides for a routable interface (Interface Tunnel 0) and therefore supports the encryption of IPmc.
Redundant VPN Headend Design
Because failsafe operation is a mandatory feature in many enterprise networks, redundancy should be
built into headend designs. From each branch location, a minimum of two tunnels should be configured
back to different headend devices. When sizing the headend installation, the failure of a single headend
device should be taken into consideration. When adding an intelligent service such as IPmc, adding
additional headend routers and spreading the load of the VPN terminations across more devices allows
for the headend routers to “share” CPU load, thus making the solution more scalable.
Note In the interest of clarity and brevity, many of the examples shown in this design guide show only a single
headend router in the topology. It is assumed in a customer deployment that redundant headend routers
are configured similarly to the primary headend configuration shown.
7
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
IPmc Deployment
This chapter discusses recommended and optional configurations for IPmc deployments in an encrypted
WAN topology. This section includes the following recommended guidelines:
• Use multiple rendezvous points (RPs) for high availability
• Use IP Protocol Independent Multicast (PIM) sparse mode and IP PIM Auto-RP listener.
Note Auto-RP is used in the deployment example but is not a requirement; statically configured RP
address can be used instead.
8
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
• Disable fast switching of IPmc as required on IPsec routers.
• Mark the ToS byte of IPsec packets for proper classification and bandwidth allocation.
The use of GRE keepalives can be used in p2p GRE tunnels to eliminate the need for a routing protocol.
Topology
This section provides a high-level overview as well as details of the topology in use.
Topology Overview
This topology overview divides the network into the following four major components, as shown in
Figure 1:
• Primary campus
• Secondary campus
• Disaster recovery hot site
• Remote SOHO routers
Figure 1 Topology Overview
132525
Remote
SOHO
Routers
rtp5-esevpn-gw5
rtp5-esevpn-gw4
VPN4-2651xm-1
rtp5-esevpn-gw3
Primary Campus
Secondary Campus
Disaster Recovery
Hot Site
Rendezvous Point
10.81.7.219
Video-831
Rendezvous Point
10.59.138.1
Internet
Cisco 7200VXR
9
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
Note The host names and series or model number of routers in this guide are not intended to imply
performance characteristics suitable for all customer deployments. Various models of routers were used
in developing this design guide to provide a variety of configuration examples. For example, a Cisco 831
router is typically deployed at a SOHO location rather than at a disaster recovery site.
The remote SOHO routers establish an IPsec-encrypted p2p GRE tunnel to one or more campus
locations. For purposes of illustration, only one GRE tunnel is configured and shown, but it is assumed
that in an actual customer deployment, a p2p GRE tunnel terminates at both major campus locations.
Another option is for the customer to advertise a network prefix encompassing the IPsec and p2p GRE
headend peer address from both the primary campus and the disaster recovery hot site. In the event of a
failure of the primary campus, the IPsec and p2p GRE headend peer address, router, and configuration
can be brought online at the disaster recovery site.
Two IPmc RPs are configured on routers dedicated for this purpose in the sample topology and are
located at two separate physical locations. The RP IP addresses are not manually configured on the
remote routers, but rather IP PIM Auto-RP is used. The interfaces of the routers are configured as IP PIM
Sparse Mode and the ip pim autorp listener global configuration command is used on all remote
routers. This command allows IP PIM Auto-RP to function over IP PIM Sparse Mode interfaces. The
rendezvous points transmit an RP-Discovery to the Cisco discovery multicast group (224.0.1.40). The
remote routers join the 224.0.1.40 group when ip pim autorp listener is configured.
The WAN links in this topology consist of broadband DSL and cable for the remote branch routers, DS3
or greater Internet links at the campus, and FastEthernet and GigabitEthernet between the primary,
secondary, and disaster recovery site.
Detailed Topology
In a closer look at the topology, the individual remote routers are identified as well as the p2p GRE tunnel
interface numbers on the headend IPsec and GRE router. All remote routers use the nomenclature of
Tunnel0 for their primary p2p GRE tunnel, and Tunnel1 (where configured) as their backup or secondary
p2p GRE tunnel. (See Figure 2.)
10
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
Figure 2 Topology Video Surveillance
The IPsec headend router uses dynamic crypto maps and static p2p GRE tunnels. A DMVPN
configuration using multipoint GRE (mGRE) and Next Hop Resolution Protocol (NHRP) is a suitable
alternative, and this configuration is used as discussed in Performance Testing, page 33. However,
DMVPN and VTI do not support GRE keepalive, which is used in this sample configuration. As such, a
dynamic IGP routing protocol such as EIGRP is configured.
To demonstrate the IPmc configuration, several IPmc-capable Panasonic WV-NM100 network color
cameras are deployed. These cameras can source MPEG-4 compressed video streams to a configurable
UDP unicast or multicast IP address, and are a feature rich and relatively inexpensive means of
generating and viewing an IPmc application.
For more information on these cameras, see the following URL: http://www.panasonic.com.
Point-to-Point GRE over IPsec Configuration
This section provides sample configurations used in testing and internal Cisco deployments of IPmc in
a teleworker environment. The IPmc application in use consists of IP video surveillance cameras
streaming MPEG-4, both from a home office to a campus location and from the campus to the home
office.
The following examples are shown:
• Configuration commands common to most routers in the topology
• IPmc RP configuration
• Headend IPsec and p2p GRE router
132526
vpn3-7200-1
Cisco
Network
rtp5-esevpn-gw5
rtp5-esevpn-gw4
VPN4-2651xm-1
rtp5-esevpn-gw3
Rendezvous Point
10.81.7.219
Video-831
Rendezvous Point
10.59.138.1
Camera 2
Penguin
Multicast_RP
ESE Lab Network
Internet
Cisco
7200VXR
Camera 1
PENGUIN_3
Video-1751
Johnjo-vpn [1841]
rtp9-ese-test [1751]
vpn-jk2-1711-vpn
Tunnel 212
Tunnel 216
Tunnel 224
Tunnel 232
Tunnel 136
Tunnel 104
11
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
• Secondary campus and disaster recovery
• Disaster recovery host site router
• Remote branch routers
Common Configuration Commands
The configurations provided in this section are common to most routers in the sample topology, and as
such, are provided in this section to avoid repetition in the later sections.
IPmc Commands
On the routers in this topology, IPmc routing is enabled globally, interfaces required to participate in the
IPmc domain have IP PIM Sparse Mode enabled, and all routers except the IPmc RP routers are
configured as IP PIM Auto-RP listeners.
!
ip multicast-routing
!
ip pim autorp listener
!
no ip pim dm-fallback
!
interface Ethernet0
description [Inside Interface]
ip pim sparse-mode
!
interface Tunnel0
ip pim sparse-mode
no ip mroute-cache
!
Note Because of CSCdu87170 (“IP Multicast not working over GRE tunnel when IPsec is enabled”), these
configurations all process switch (no ip mroute-cache) IPmc packets.
Without implementing one of the problem circumventions listed, the IPmc encapsulated packets are
transmitted out the outside interface in the clear. This presents a security exposure.
The no ip pim dm-fallback command prevents PIM Dense Mode fallback if all rendezvous points fail.
This feature was introduced in Cisco IOS release 12.3(4)T.
QoS Configuration
The QoS configuration is similar to configurations used in V3PN deployments. Because the sample IPmc
application is video surveillance, a VIDEO-surveillance class is included. Most Cisco IOS router
hardware platforms support re-marking the ToS byte on an input interface, and as an illustration, the
IPmc address space is remarked to IP Precedence 4 or DSCP value of CS4.
The output service policy allocates bandwidth for video surveillance as a percentage of the shaped rate.
The percentage value should be adjusted based on the available bandwidth and the image size, quality,
resolution, and encoding.
In this set of tests, voice, video, and data is present on the broadband link concurrently. The link speed
in some cases was below 768 Kbps, and the ip tcp adjust-mss command is configured. The value of 542
is used on interfaces with IPsec direct encapsulation or unencrypted packets, and a value of 574 is used
on interfaces with p2p GRE or mGRE and IPsec encryption.
12
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
!
class-map match-all VOICE
match ip dscp ef
class-map match-any CALL-SETUP
match ip dscp af31
match ip dscp cs3
class-map match-any INTERNETWORK-CONTROL
match ip dscp cs6
match access-group name IKE
class-map match-any VIDEO-surveillance
match ip dscp cs4
match access-group name IPmc
!
ip access-list extended IPmc
permit udp any 224.0.0.0 15.255.255.255 # Class ‘D’ address space
!
ip access-list extended IKE
permit udp any eq isakmp any eq isakmp
!
policy-map V3PN-teleworker
description Note LLQ for ATM/DSL G.729=64K, G.711=128K
class CALL-SETUP
bandwidth percent 2
class INTERNETWORK-CONTROL
bandwidth percent 5
class VOICE
priority 128
class VIDEO-surveillance
bandwidth percent 45 # Value depends on bandwidth and Video image
queue-limit 10
class class-default
fair-queue
random-detect
policy-map Shaper
class class-default
shape average 608000 6080 # Depends on link speed this value is used on a
# Business class cable connection that is 768K up
service-policy V3PN-teleworker
!
!
interface Ethernet1
description Outside
service-policy output Shaper
ip route-cache flow
ip tcp adjust-mss 542
interface Tunnel0
ip mtu 1408
ip tcp adjust-mss 574
qos pre-classify
!
! # Where supported, Video packets are marked on
! # ingress. Not all IOS images support this feature
!
policy-map INGRESS
class VIDEO-surveillance
set ip dscp cs4
!
!
interface FastEthernet0/1
!
service-policy input INGRESS
13
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
IPsec Configuration
The IPsec configuration is characterized by the following features:
• Digital certificates (PKI)
• IKE encrypted with 3DES and Diffie-Hellman group 2
• Dead Peer Detection and NAT Transparency (NAT-T) keepalives
• IPsec encrypted with 3DES, HMAC of SHA-1, and tunnel mode
• The branch router p2p GRE tunnel source is an RFC1918 address on Loopback1
• Headend routers use dynamic crypto maps
The outside interface is protected by an input access control list (ACL) where appropriate. Examples of
the ACL and the spouse-and-child security configuration are shown in later configuration examples.
!
crypto pki trustpoint rtp5-esevpn-ios-ca
enrollment url http://rtp5-esevpn-ios-ca:80
revocation-check none
source interface Ethernet0
auto-enroll 70
!
crypto pki certificate chain rtp5-esevpn-ios-ca
certificate 2E
certificate ca 01
!
crypto isakmp policy 100
encr 3des
group 2
crypto isakmp keepalive 10
crypto isakmp nat keepalive 10
!
crypto ipsec transform-set 3DES_SHA_TUNNEL esp-3des esp-sha-hmac
crypto ipsec transform-set 3DES_SHA_TRANSPORT esp-3des esp-sha-hmac
mode transport
!
crypto map Encrypt_GRE 10 ipsec-isakmp
set peer xx.xxx.223.23
set transform-set 3DES_SHA_TUNNEL
match address Encrypt_GRE
!
ip access-list extended Encrypt_GRE
permit gre host
_tunnel_source
host xx.xxx.223.23
!
interface Loopback1
description Anchor for GRE tunnel
ip address
_tunnel_source
255.255.255.255
!
interface Tunnel0
tunnel source Loopback1
tunnel destination xx.xxx.223.23
!
interface Ethernet1
description Outside
ip address dhcp
ip access-group INPUT_ACL in
no cdp enable
crypto map Encrypt_GRE
!
!
14
Multicast over IPsec VPN Design Guide
OL-9028-01
IPmc Deployment
Other Configuration Commands
These configuration commands are not characterized by the previous classifications. Note the following:
• Cisco Express Forwarding (CEF) is configured.
• Services such has SNMP, Syslog, Telnet, and TFTP are sourced so that they are protected by the
encrypted p2p GRE tunnel.
• IP SLA, formerly known as Service Assurance Agent (SAA), is configured to provide a history for
troubleshooting.
!
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
clock timezone est -5
clock summer-time edt recurring
no aaa new-model
ip subnet-zero
!
ip telnet source-interface Ethernet0 # Inside Interface
ip tftp source-interface Ethernet0 # Inside Interface
no ip domain lookup
ip domain name cisco.com
!
ip host rtp5-esevpn-ios-ca 10.81.0.27
ip host vpn3-7200-1 10.59.138.1
ip host multicast-RP 10.81.7.219
ip host harry 172.26.129.252
ip host CAMERA2 10.59.138.21
ip host CAMERA1 10.81.7.227
!
ip name-server 207.69.188.185
ip cef
!
ip classless
!
ip access-list extended INPUT_ACL
remark Allow IKE and ESP from the RTP headends
permit udp xx.xxx.223.16 0.0.0.15 any eq isakmp
permit udp xx.xxx.223.16 0.0.0.15 any eq non500-isakmp
permit esp xx.xxx.223.16 0.0.0.15 any
permit gre xx.xxx.223.16 0.0.0.15 any
permit udp any any eq bootpc
remark NTP ACLs
permit udp 192.5.41.40 0.0.0.1 eq ntp any
permit udp host 216.210.169.40 eq ntp any
remark SSH
permit tcp xx.xxx.87.0 0.0.0.255 any eq 22
permit icmp any any
deny ip any any
no ip http server
no ip http secure-server
ip flow-export version 5
!
logging source-interface
Ethernet0
# Logging will be source always on the inside
# interface so they are encrypted
#
#
rtr responder
Đăng ký:
Đăng Nhận xét (Atom)
Không có nhận xét nào:
Đăng nhận xét