Friday, October 24, 2008

GET VPN

Cisco’s Group Encrypted Transport VPN (GET-VPN) is a tunnel-less VPN technology that leverages the existing core network and routing structure to interconnect nodes.
Tunnel definitions are not used, but rather an encryption policy based on access control lists is pushed down to each node from a central server. Data encryption is “on-demand” and is only applied to traffic that meets the specification of the access control lists.

Like tunnel-based VPNs, tunnel-less GET-VPN also encrypts the entire packet, but instead of generating a new header it recycles the original IP information. This “header preservation” takes advantage of the existing core routing structure for endpoint reachability, and eliminates the need for overlaid tunnels, preserves native Quality of Service support, and provides an efficient means for any-to-any (full-mesh) connectivity and for encrypted multicast replication.


GET VPN Components


Key Server

It is responsible for accepting or rejecting members into the VPN, generating/regenerating and distributing the encryption keys, and deploying the encryption policies to all of the registered Group Members.

A single Key Server is required, but multiple Key Servers can be deployed and is recommended to provide redundancy and load balancing since the encryption function of the VPN is dependent entirely upon the availability of the Key Server.

Group Member

Group Members are the individual node devices that protect local networks and encrypt traffic based on the encryption policy provided by the Key Server.

GDOI Group

The GET-VPN concept is based upon a “trusted group” model whose members employ a common security methodology. The GDOI group configuration, specified on the Key Server, contains the parameters needed to establish and maintain encryption policies between Group Members.

Identity

The identity number is a unique value that differentiates GDOI groups configured on a Key Server. No two groups can have the same identity number. The identity number determines which group the Group Member registers to.

Rekeying

In order to prevent service outages, GET-VPN initiates unicast rekeying events a minimum of 90 seconds prior to the expiration of the existing keys. The Key Server uses several parameters to attempt to estimate more accurately when to begin the rekeying process.

In addition to the TEK and KEK lifetime parameters, the Key Server uses the rekey retransmit number and time settings, and assumes a constant rekey processing time of 5 seconds per 50 Group Members.

With unicast rekeying, Group Members respond to rekey messages by replying to the Key Server with an acknowledgement.

If the Key Server does not receive acknowledgements for three consecutive rekey messages, it ejects that Group Member from the VPN, forcing it to reregister in order to resume sending encrypted traffic.

Multicast rekeying occurs 90 seconds prior to the SA expiration, and the rekey transmit time and rekey transmit number parameters are used to control how often and for how long the rekey messages will be transmitted. This is done to counter unexpected or intermittent packet loss, since Group Members do not acknowledge the receipt of multicast rekey messages.

Anti-Replay

Anti-replay mechanisms are used to prevent the retransmission of traffic captured in transit by a third party. GET-VPN can discard packets suspected of being replayed using either of two methods – counter-based and time-based.

Counter-based

Counter-based anti-replay uses a sliding window based on the sequence number of the arriving packets. If the sequence number of a packet is outside of the lower window boundary, it is considered to be a replayed packet and is discarded.

The use of counter-based anti-replay is common in tunnel-based VPNs, where there is a single pair of endpoints that packets travel between, providing a consistent parade of sequence numbers.

Time-based

Since counter-based anti-replay is of limited use in a tunnel-less environment, GET-VPN also offers anti-replay protection based on timestamp values using a mechanism called Synchronous Anti-Replay (SAR).

SAR is a GET-VPN-specific clocking function that is not dependent on the router’s time setting or on connectivity to an NTP source. The SAR clock runs continuously and tracks “pseudotime” in seconds, beginning with the successful registration of the first Group Member. The “authoritative” pseudotime is maintained by the Key Server and the current pseudotime value is periodically sent to the Group Members within a rekey message, effectively synchronizing the VPN.

The current pseudotime value is included with each encrypted packet that is created by a Group Member. When the packet arrives at the receiving Group Member, it compares the pseudotime value contained in the packet (the “pseudoTimeStamp”) with the running pseudotime value that it is maintaining. If the pseudoTimeStamp of the packet and the Group Member pseudotime are within the configured anti-replay window, then the packet is accepted.

CONFIGURATION

IKE Phase 1 Policy Commands using preshared key

crypto isakmp policy [IKE-Priority]

encryption [IKE-Encryption]

hash [IKE-Hash-Algorithm]

authentication pre-shared

group [IKE-DH-Group]

lifetime [IKE-SA-Lifetime]

crypto isakmp key 0 [KEY] address [GroupMember-IP-Address]

Key Server Configuration Commands

crypto key generate rsa label [NAME] modulus [MODULUS] (exportable)

crypto isakmp policy [IKE-Priority]

encryption [IKE-Encryption]

hash [IKE-Hash]

authentication pre-share

group [IKE-DH-Group]

lifetime [IKE-SA-Lifetime]

crypto isakmp key 0 [KEY] address [GroupMember]

crypto ipsec transform-set [NAME] [KEY] [HASH]

crypto ipsec profile [NAME]

set transform-set [NAME]

ip access-list extended [NAME]

permit [protocol] [source] [destination]

crypto gdoi group [NAME]

identity number [ID]

server local

rekey algorithm [TYPE]

rekey lifetime seconds [Lifetime]

rekey retransmit [TIME] number [NUMBER]

rekey authentication mypubkey rsa [RekeyNAME]

rekey transport unicast

registration interface [NAME]

address ipv4 [KeyServer]

sa ipsec [NUMBER]

profile [NAME]

match address ipv4 [NAME]

replay time window-size [SIZE]


Group Member Configuration Commands

crypto isakmp key 0 [Key] address [KeyServer]

crypto gdoi group [NAME]

identity number [Number]

server address ipv4 [KeyServer]

crypto map [NAME] [Sequence] gdoi

set group [NAME]

interface [WAN]

crypto map [NAME]

interface [WAN]

ip mtu 1480

Case Study

Key Server 1: Example

Key server 1 is the primary key server.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service internal

hostname KS1

!

logging buffered 100000 debugging

no logging console

!

no aaa new-model

!

clock timezone EST 0

ip subnet-zero

no ip domain lookup

ip domain name cisco.com

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 400

crypto isakmp key cisco address 10.1.1.13

crypto isakmp key cisco address 10.1.1.9

crypto isakmp key cisco address 10.1.1.1

crypto isakmp key cisco address 10.1.1.5

crypto isakmp key cisco address 10.1.1.21

!

crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmac

!

crypto ipsec profile gdoi-profile-group1

set security-association lifetime seconds 1800

set transform-set gdoi-trans-group1

!

crypto gdoi group group1

identity number 1

server local

rekey lifetime seconds 86400

rekey retransmit 10 number 2

rekey authentication mypubkey rsa group1-export-general

rekey transport unicast

sa ipsec 1

profile gdoi-profile-group1

match address ipv4 101

replay counter window-size 64

address ipv4 10.1.1.17

redundancy

local priority 10

peer address ipv4 10.1.1.2

!

interface Ethernet0/0

ip address 10.1.1.17 255.255.255.252

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.1.18

!

access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255

!

end

Key Server 2: Example

Key Server 2 is the secondary key server.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service internal

!

hostname KS2

!

logging buffered 100000 debugging

no logging console

!

no aaa new-model

!

resource policy

!

clock timezone EST 0

ip subnet-zero

no ip domain lookup

ip domain name cisco

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 400

crypto isakmp key cisco address 10.1.1.9

crypto isakmp key cisco address 10.1.1.1

crypto isakmp key cisco address 10.1.1.5

crypto isakmp key cisco address 10.1.1.17

crypto isakmp key cisco address 10.1.1.13

!

crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmac

!

crypto ipsec profile gdoi-profile-group1

set security-association lifetime seconds 1800

set transform-set gdoi-trans-group1

!

crypto gdoi group group1

identity number 1

server local

rekey lifetime seconds 86400

rekey retransmit 10 number 2

rekey authentication mypubkey rsa group1-export-general

rekey transport unicast

sa ipsec 1

profile gdoi-profile-group1

match address ipv4 101

replay counter window-size 64

address ipv4 10.1.1.21

redundancy

local priority 1

peer address ipv4 10.1.1.17

!

interface Ethernet0/0

ip address 10.1.1.21 255.255.255.252

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.1.1.22

!

access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255

!

end

Group Member 1: Example

Group Member 1 is part of a GDOI group that correlates with a VPN with which these sites are a part.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname GM1

!

resource policy

!

clock timezone EST 0

ip subnet-zero

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 3600

crypto isakmp key cisco address 10.1.1.17

crypto isakmp key cisco address 10.1.1.21

!

crypto gdoi group group1

identity number 1

server address ipv4 10.1.1.17

server address ipv4 10.1.1.21

!

crypto map map-group1 10 gdoi

set group group1

!

interface Ethernet0/0

ip address 10.1.1.1 255.255.255.252

crypto map map-group1

!

router bgp 1000

no synchronization

bgp log-neighbor-changes

network 10.1.1.0 mask 255.255.255.0

neighbor 10.1.1.2 remote-as 5000

no auto-summary

!

ip classless

!

End

Group Member 2: Example

Group Member 2 is part of a GDOI group that correlates with a VPN with which these sites are a part.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname GM2

!

clock timezone EST 0

ip subnet-zero

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 3600

crypto isakmp key cisco address 10.1.1.17

crypto isakmp key cisco address 10.1.1.21

!

crypto gdoi group group1

identity number 1

server address ipv4 10.1.1.17

server address ipv4 10.1.1.21

!

crypto map map-group1 10 gdoi

set group group1

!

interface Ethernet0/0

ip address 10.1.1.5 255.255.255.252

crypto map map-group1

!

router bgp 2000

no synchronization

bgp log-neighbor-changes

network 10.1.2.0 mask 255.255.255.0

neighbor 10.1.1.6 remote-as 5000

no auto-summary

!

ip classless

!

end

Group Member 3: Example

Group Member 3is part of a GDOI group that correlates with a VPN with which these sites are a part.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname GM3

!

resource policy

!

clock timezone EST 0

ip subnet-zero

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 3600

crypto isakmp key cisco address 10.1.1.17

crypto isakmp key cisco address 10.1.1.21

!

crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmac

crypto gdoi group group1

identity number 1

server address ipv4 10.1.1.17

server address ipv4 10.1.1.21

!

crypto map map-group1 10 gdoi

set group group1

!

interface Ethernet0/0

ip address 10.1.1.9 255.255.255.252

crypto map map-group1

!

router bgp 3000

no synchronization

bgp log-neighbor-changes

network 10.1.3.0 mask 255.255.255.0

neighbor 10.1.1.10 remote-as 5000

no auto-summary

!

ip classless

!

end

Group Member 4: Example

Group Member 4 is part of a GDOI group that correlates with a VPN with which these sites are a part.

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname GM4

!

clock timezone EST 0

ip subnet-zero

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

lifetime 3600

crypto isakmp key cisco address 10.1.1.17

crypto isakmp key cisco address 10.1.1.21

!

crypto gdoi group group1

identity number 1

server address ipv4 10.1.1.17

server address ipv4 10.1.1.21

!

crypto map map-group1 10 gdoi

set group group1

!

interface Ethernet0/0

ip address 10.1.1.13 255.255.255.252

crypto map map-group1

!

router bgp 4000

no synchronization

bgp log-neighbor-changes

network 10.1.4.0 mask 255.255.255.0

neighbor 10.1.1.14 remote-as 5000

no auto-summary

!

ip classless

!

end


For more Information on GET VPN:


Design and Implementation Guide

RFC 3547

GDOI in DMVPN

DNS Exploit

Computer Academic Underground
Exploit Code

===============/========================================================
Exploit ID: CAU-EX-2008-0002
Release Date: 2008.07.23
Title: bailiwicked_host.rb
Description: Kaminsky DNS Cache Poisoning Flaw Exploit
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Author/Email: I)ruid
H D Moore
===============/========================================================

Description
===========

This exploit targets a fairly ubiquitous flaw in DNS implementations which allow the insertion of malicious DNS records into the cache of the target nameserver. This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query
for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the

Cisco's take on the exploit:

http://tools.cisco.com/security/center/viewAlert.x?alertId=16183

Defending using IPS DNS flood attack

Using ASA/PIX firewall

DNS Application Inspection Configuration


DNS application inspection utilizes the Modular Policy Framework (MPF) for configuration. To configure application inspection, administrators may construct an inspection policy through the configuration of inspect class maps and inspect policy maps, which are applied via a global or an interface service policy. The following example demonstrates configuration of this feature.

!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
!
!– Enable dns-guard to verify that DNS query and response transaction IDs match and only one ! DNS response is allowed through the firewall for each query.
!
dns-guard
!
!– Enable id-randomization to generate unpredictable DNS transaction IDs in !DNS messages and protect DNS servers and resolvers with poor randomization of !DNS transaction IDs.
!
id-randomization
!
!– Enable a maximum message length to help defeat DNS amplification attacks. Note: This is the ! default configuration and value based on RFC 1035.
!
message-length maximum 512
!
!– Enable id-mismatch to count DNS transaction ID mismatches within a specified period of time !and generate a syslog when the defined threshold has been reached.
!
id-mismatch count 10 duration 2 action log
exit
!
!– Check for DNS query messages with the recursion desired (RD) flag set in the DNS header !and drop those packets to avoid being used as a recursive resolver.

match header-flag RD
drop
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
!
service-policy global_policy global


DNS Attack Identification


DNS Service Policy Identification
When the DNS guard, DNS ID randomization, DNS ID mismatch, and DNS protocol enforcement functions for the DNS application inspection feature are enabled, the show service-policy inspect command will identify the number of DNS packets inspected or dropped by these functions and this feature. Example output for show service-policy inspect dns follows

!– Output for service-policy applied globally
!
firewall# show service-policy inspect dns

Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 37841, drop 0, reset-drop 0
message-length maximum 512, drop 0
dns-guard, count 21691
protocol-enforcement, drop 0
nat-rewrite, count 0
id-randomization, count 21856
id-mismatch count 10 duration 2, log 2
firewall#

!– Output for service-policy applied per interface
!
firewall# show service-policy inspect dns

Interface outside:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 4923, drop 1544, reset-drop 0
message-length maximum 512, drop 39
dns-guard, count 2147
protocol-enforcement, drop 542
nat-rewrite, count 0
id-randomization, count 2220
id-mismatch count 10 duration 2, log 1

Interface inside:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 240, drop 0, reset-drop 0
message-length maximum 512, drop 0
dns-guard, count 88
protocol-enforcement, drop 0
nat-rewrite, count 0
id-randomization, count 116
id-mismatch count 10 duration 2, log 0
firewall#

Syslog Identification

In the following example, the show logging | grep regex command extracts syslog messages from the logging buffer on the firewall. These messages provide additional information about denied packets. It is possible to use different regular expressions with the grep keyword to search for specific data in the logged messages.

Firewall syslog message 410002 will be generated when the firewall detects a high rate of DNS responses with a mismatched DNS transaction ID. The threshold for this function is set by the id-mismatch parameters submode command for policy-map type inspect dns. Additional information about this syslog message is available in Cisco Security Appliance System Log Message - 410002.

Firewall syslog message 106007 will be generated when the firewall detects that a DNS response message has already been received for a DNS query message and the connection entry has been torn down by the DNS guard function. This syslog message indicates that the DNS response message received has been denied. Additional information about this syslog message is available in Cisco Security Appliance System Log Message - 106007.

Additional information about regular expression syntax is available in Using the Command Line Interface.


firewall#Ashow logging | grep (106007|410002)
Mar 31 2008 00:29:18: %ASA-2-410002: Dropped 189 DNS responses with
mis-matched id in the past 10 second(s): from outside:192.0.2.2/3917
to inside:192.168.60.1/53
Mar 31 2008 00:29:13: %ASA-2-106007: Deny inbound UDP from 192.0.2.2/2875
to 192.168.60.1/53 due to DNS Response.
firewall#

Monday, October 20, 2008

DMVPN with NHRP

Basic DMVPN overview

dmvpn_04.gif


In a dual cloud topology, two DMVPN networks are used to exchange traffic between devices. Two mGRE or two P2P-GRE interfaces are configured at each site not each device. Two tunnels are configured on a single CPE site and two tunnels are configured on a dual CPE site (one tunnel per CPE device). Dual Cloud Topologies can support the Hub and Spoke Deployment Model and the Spoke-to-Spoke Deployment Model. Multiple NHRP servers are required at the hub site (one for each cloud). Also, this helps to protect the customer’s hub from a single point failure.

Basic DMVPN Configuration

====================
! IKE Policy Configuration
!===================
! Creates the ISAKMP policy named “1″.
crypto isakmp policy 1
! Sets the encryption algorithm for protection suite.
encr aes 256
! Sets the hash algorithm for protection suite.
hash sha
! Sets the authentication method for protection suite.
authentication pre-share
! Set the Diffie-Hellman group.
group 5
! Set lifetime for ISAKMP security association
lifetime 86400
! Sets a wildcard pre-shared key for remote peers.
crypto isakmp key [PRESHARED_KEY] address 0.0.0.0
! Sets the keepalive interval for use with all peers. The Number of seconds
! between keep alives is set to 10. The number of seconds between retries
! is set to 4. The on-demand mode only sends DPD messages when needed.
crypto isakmp keepalive 10 4 on-demand
!===================
! IKE Policy Configuration
!===================

crypto isakmp policy 1
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 86400
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 10 4 on-demand

!=====================
! IPSEC Policy Configuration
!=====================
! Creates an IPSEC transform named “T1″ and defines the associated settings.
crypto ipsec transform-set T1 esp-aes 256 esp-sha-hmac
! Sets the IPSEC mode of opration to “transport” mode.
mode transport
! Creates an IPSEC policy profile named “P1″.
crypto ipsec profile P1
! Specifies the transform set to be used.
set transform-set T1
! Specifies the PFS Diffie-Hellman group.
set pfs group5

!====================
! IPSEC Policy Configuration
!====================

crypto ipsec transform-set T1 esp-aes 256 esp-sha-hmac
mode transport
crypto ipsec profile P1
set transform-set T1
set pfs group5

!================
! Hub - DMVPN Tunnel
!================

! Creates a tunnel interface.
interface Tunnel 0
! Defines the interface description.
description DMVPN Hub Primary Cloud
! Sets the bandwidth informational parameter.
bandwidth 10000
! Sets the IP address of the tunnel interface.
ip address [TUNNEL_IP] [TUNNEL_MASK]
! Sets the IP Maximum Transmission Unit.
ip mtu 1400
! Sets the NHRP authentication string.
ip nhrp authentication [NHRP_PRESHARED_KEY]
! Dynamically learn NBMA mapping for broadcasts/multicasts
ip nhrp map multicast dynamic
! Sets the NHRP NBMA network identifier.
ip nhrp network-id [NHRP_NETWORK_ID]
! Sets the NHRP advertised holdtime.
ip nhrp holdtime 600
! Specifies the interface throughput delay.
delay [TUNNEL_DELAY]
! Sets the source IP address of the tunnel packets.
tunnel source [PUBLIC_INTERFACE_INSTANCE]
! Enables Multipoint GRE mode.
tunnel mode gre multipoint
! Sets a tunnel security or selector key.
tunnel key [TUNNEL_KEY]
! Enables IPSEC tunnel protection.
tunnel protection ipsec profile P1

!=================
! Hub - DMVPN Tunnel
!=================

interface Tunnel 0
description DMVPN Hub Primary Cloud
bandwidth 10000
ip address 172.17.0.1 255.255.255.0
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
delay 100
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile P1

!===================
! Spoke - DMVPN Tunnel
!===================

! Creates a tunnel interface.
interface Tunnel [TUNNEL_INSTANCE]
! Defines the interface description.
description [TUNNEL_DESCRIPTION]
! Sets the bandwidth informational parameter.
bandwidth 10000
! Sets the IP address of the tunnel interface.
ip address [TUNNEL_IP] [TUNNEL_MASK]
! Sets the IP Maximum Transmission Unit.
ip mtu 1400
! Sets the NHRP authentication string.
ip nhrp authentication [NHRP_PRESHARED_KEY]
! Creates a static NHRP mapping for the hub router.
ip nhrp map [HUB_TUNNEL_IP] [HUB_PUBLIC_IP]
! NBMA mapping for broadcasts/multicasts. Used to dynamically learn
! destinations from client registrations on hub.
ip nhrp map multicast [HUB_PUBLIC_IP]
! Sets the NHRP NBMA network identifier.
ip nhrp network-id [NHRP_NETWORK_ID]
! Sets the NHRP advertised holdtime.
ip nhrp holdtime 600
! Sets the IP address of the NHRP server located at the hub.
ip nhrp nhs [HUB_TUNNEL_IP]
! Specifies the interface throughput delay.
delay [TUNNEL_DELAY]
! Sets the source IP address of the tunnel packets.
tunnel source [PUBLIC_INTERFACE_INSTANCE]
! Sets the destination IP address of the tunnel packets.
tunnel destination [HUB_PUBLIC_IP]
! Sets a tunnel security or selector key.
tunnel key [TUNNEL_KEY]
! Enables IPSEC tunnel protection.
tunnel protection ipsec profile P1

!===================
! Spoke - DMVPN Tunnel
!===================

interface Tunnel 0
description DMVPN Spoke Primary Cloud
bandwidth 10000
ip address 172.17.0.2 255.255.255.0
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map 172.17.0.1 10.0.0.1
ip nhrp map multicast 10.0.0.1
ip nhrp network-id 1
ip nhrp holdtime 600
ip nhrp nhs 172.17.0.1
delay 100
tunnel source FastEthernet0
tunnel destination 10.0.0.1
tunnel key 1
tunnel protection ipsec profile P1


Next-Hop Resolution Protocol (NHRP)

When traffic is exchanged between two devices in a DMVPN network, the devices must learn where the GRE interface for the other device publicly resides in the NBMA network. This information is learnt through the Next-Hop Resolution Protocol (NHRP). When a device on the Spoke’s private network initiates a session to a device on the Hub’s private network, a routing table lookup is executed and determines the destination network is reachable through IP address 10.0.0.1 via interface Tunnel 0. The session traffic is then forwarded out the Tunnel0 interface where an NHRP lookup is executed. The map entry in the Spoke NHRP Table indicates the Hub GRE (End-Point) is located at NBMA IP address 10.0.0.1. From this information, the session traffic is forwarded out a dynamic GRE/IPSEC tunnel to the hub as demonstrated in the diagram. The Hub receives the session traffic and forwards it to the destination device.

NHRP Registration Order of Operation

A static NHRP mapping is configured for the NHRP server configured at the Hub which forces the spoke to initiate an NHRP Registration Request to the Hub. The NHRP Registration Request causes an IKE session to be initiated with the Hub. Once the IKE/IPSEC sessions are established, the NHRP Registration request is forward over the IPSEC/GRE tunnel.

The Hub processes the NHRP Registration Request received from Spoke1, creates an entry in the NHRP table and sends an NHRP Registration Reply to Spoke1 indicating the spoke was successfully registered.

Data exchanged between the hub and spokes are sent over the IPSEC/GRE tunnel.

Route Reflector

From RFC4456

The Border Gateway Protocol is an inter-autonomous system routing protocol designed for TCP/IP Internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. For n BGP speakers within an AS that requires to maintain n*(n-1)/2 unique IBGP sessions. This “full mesh” requirement clearly does not scale when there are a large number of IBGP speakers each exchanging a large volume of routing information, as is common in many of todays Internet. This scaling problem could be elevated in a couple of ways. One of them is the use of “Route Reflectors”.

In AS X there are three IBGP speakers (routers RTR-A, RTR-B and RTR-C). With the existing BGP model, if RTR-A receives an external route and it is selected as the best path it must advertise the external route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers) will not re-advertise these IBGP learned routes to other IBGP speakers. If this rule is relaxed and RTR-C is allowed to advertise IBGP learned routes to IBGP peers, then it could re-advertise (or reflect) the IBGP routes learned from RTR-A to RTR-B and vice versa. This would eliminate the need for the IBGP session between RTR-A and RTR-B
This is the basic principle of Route Reflection scheme

Route Reflector is a router that can perform the route reflection function. The IBGP peers of the route- reflector fall into two categories clients and non-clients. A route reflector and its clients form a cluster. All the peers that are not part of the cluster are called as non-clients.

The route reflector function is implemented only on the route reflector; all clients and non-clients are normal BGP peers. Any route reflector that receives multiple routes for the same destination will pick the best path based on the normal BGP decision process. The best path would be propagated within the AS based on the following:

Ø Routes received from a non-client peer, the route will be reflected to clients only.

Ø Routes received from a client peer, the routes are reflected to all non-client and client peers except for the route originator.

Ø Routes received from EBGP peer, the route will be reflected to all clients and non-clients.

The route reflector preserves IBGP attributes, for example the next-hop attribute remains intact when the routes are exchanged between route reflectors. To avoid Loops inside an AS, the route reflectors use

Ø Originator ID, which carries the router-id of the originator of the route in an AS.

Ø Cluster List, when the route reflector sends a route from its clients to non-clients outside the cluster, the route reflector appends the local cluster-ID to the cluster-list.

Per RFC 4456, Usually, a cluster of clients will have a single RR. In that case, the cluster will be identified by the BGP Identifier of the RR. However, this represents a single point of failure so to make it possible to have multiple RRs in the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster.

So question arise on whether you should use the same cluster-id for route reflectors within a cluster? There are generally speaking, 2 forms of RR cluster design:

First, the route reflectors have the same cluster-ID.

1) Loop prevention using Cluster-list and Originator-ID concept.
2) One Path from each Route Reflector client.
3) 100% redundancy difficult to accomplish. ( using loopbacks you can get close to 100%).
4) comparatively less memory and cpu Utilization.

Second, the router reflectors have different cluster-ID

1) One Path from Router Reflector Client and one path from Route Reflector (you just doubled the size of your bgp table!, Hence more memory consumption).
2) You can achive 100% redundancy.
3) BGP has to do more work as it has 2 paths for each prefix, hence more CPU Utilization.

So depends on your network, one might chose different path for Route Reflector design and implementation.

Spoke_R1

router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.42.0.0 mask 255.255.254.0
neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.1 update-source Tunnel0
neighbor 10.0.8.2 remote-as 65000
neighbor 10.0.8.2 update-source Tunnel1
no auto-summary

luan1811#show ip bgp neigh
BGP neighbor is 10.0.0.1, remote AS 65000, internal link
BGP version 4, remote router ID 208.209.251.213
BGP state = Established, up for 00:10:58
Last read 00:00:58, last write 00:00:58, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 2 5
Keepalives: 784 784
Route Refresh: 0 1
Total: 788 792
Default minimum time between advertisement runs is 0 seconds

For address family: IPv4 Unicast
BGP table version 3, neighbor version 3/0
Output queue size: 0
Index 1, Offset 0, Mask 0×2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 1 (Consumes 52 bytes)
Prefixes Total: 1 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
ORIGINATOR loop: n/a 1
Bestpath from this peer: 1 n/a
Total: 1 1
Number of NLRIs in the update sent: max 1, min 1

Connections established 2; dropped 1
Last reset 00:10:59, due to User reset
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 10.0.0.11, Local port: 25531
Foreign host: 10.0.0.1, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0×2CF0578):
Timer Starts Wakeups Next
Retrans 16 0 0×0
TimeWait 0 0 0×0
AckHold 14 12 0×0
SendWnd 0 0 0×0
KeepAlive 0 0 0×0
GiveUp 0 0 0×0
PmtuAger 0 0 0×0
DeadWait 0 0 0×0
Linger 0 0 0×0
ProcessQ 0 0 0×0

iss: 24463755 snduna: 24464122 sndnxt: 24464122 sndwnd: 16018
irs: 2963419477 rcvnxt: 2963419927 rcvwnd: 15935 delrcvwnd: 449

SRTT: 264 ms, RTTO: 545 ms, RTV: 281 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1360 bytes):
Rcvd: 19 (out of order: 0), with data: 17, total data bytes: 449
Sent: 30 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 16, total data bytes: 366
Packets received in fast path: 0, fast processed: 0, slow path: 0
Packets send in fast path: 0
fast lock acquisition failures: 0, slow path: 0

luan1811#show ip bgp neigh
BGP neighbor is 10.0.0.1, remote AS 65000, internal link
BGP version 4, remote router ID 208.209.251.213
BGP state = Established, up for 00:10:58
Last read 00:00:58, last write 00:00:58, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 2 5
Keepalives: 784 784
Route Refresh: 0 1
Total: 788 792
Default minimum time between advertisement runs is 0 seconds

For address family: IPv4 Unicast
BGP table version 3, neighbor version 3/0
Output queue size: 0
Index 1, Offset 0, Mask 0×2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 1 (Consumes 52 bytes)
Prefixes Total: 1 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
ORIGINATOR loop: n/a 1
Bestpath from this peer: 1 n/a
Total: 1 1
Number of NLRIs in the update sent: max 1, min 1

Connections established 2; dropped 1
Last reset 00:10:59, due to User reset
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 10.0.0.11, Local port: 25531
Foreign host: 10.0.0.1, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0×2CF0578):
Timer Starts Wakeups Next
Retrans 16 0 0×0
TimeWait 0 0 0×0
AckHold 14 12 0×0
SendWnd 0 0 0×0
KeepAlive 0 0 0×0
GiveUp 0 0 0×0
PmtuAger 0 0 0×0
DeadWait 0 0 0×0
Linger 0 0 0×0
ProcessQ 0 0 0×0

iss: 24463755 snduna: 24464122 sndnxt: 24464122 sndwnd: 16018
irs: 2963419477 rcvnxt: 2963419927 rcvwnd: 15935 delrcvwnd: 449

SRTT: 264 ms, RTTO: 545 ms, RTV: 281 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1360 bytes):
Rcvd: 19 (out of order: 0), with data: 17, total data bytes: 449
Sent: 30 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 16, total data bytes: 366
Packets received in fast path: 0, fast processed: 0, slow path: 0
Packets send in fast path: 0
fast lock acquisition failures: 0, slow path: 0

HUB_Route_Reflector

BBSite1R1#show run | b router bgp
router bgp 65000
no synchronization
bgp cluster-id 1
bgp log-neighbor-changes
neighbor 10.0.0.11 remote-as 65000
neighbor 10.0.0.11 update-source Tunnel0
neighbor 10.0.0.11 route-reflector-client
neighbor 10.0.0.71 remote-as 65000
neighbor 10.0.0.71 update-source Tunnel0
neighbor 10.0.0.71 route-reflector-client
neighbor 10.1.1.2 remote-as 65000
no auto-summary

BBSite1R1#show ip bgp sum
BGP router identifier 208.209.251.213, local AS number 65000
BGP table version is 5, main routing table version 5
2 network entries using 240 bytes of memory
2 path entries using 104 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 624 total bytes of memory
BGP activity 3/1 prefixes, 4/2 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.11 4 65000 801 805 5 0 0 00:23:13 1
10.0.0.71 4 65000 815 818 5 0 0 13:29:47 1
10.1.1.2 4 65000 798 798 5 0 0 13:07:51 0

BBSite1R1#show ip bgp
BGP table version is 5, local router ID is 208.209.251.213
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i10.7.1.0/24 10.0.0.71 0 100 0 i
*>i10.42.0.0/23 10.0.0.11 0 100 0 i

DEBUG IP BGP UPDATE

BBSite1R1#clear ip bgp 10.1.1.2
BBSite1R1#
007464: Jun 30 12:28:13.531 EDT: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Down User reset
007465: Jun 30 12:28:14.587 EDT: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up
007466: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 send UPDATE (format) 10.42.0.0/23, next 10.0.0.11, metric 0, path Local
007467: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 send UPDATE (format) 10.7.1.0/24, next 10.0.0.71, metric 0, path Local
007468: Jun 30 12:28:14.587 EDT: BGP: 10.1.1.2 RR in same cluster. Reflected update dropped
007469: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 rcv UPDATE w/ attr: nexthop 10.0.8.11, origin i, localpref 100, metric 0, originator 172.16.42.1, clusterlist 0.0.0.1, path , community , extended community
007470: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 rcv UPDATE about 10.42.0.0/23 — DENIED due to: reflected from the same cluster;
BBSite1R1#
007471: Jun 30 12:28:14.587 EDT: BGP: 10.1.1.2 RR in same cluster. Reflected update dropped
007472: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 rcv UPDATE w/ attr: nexthop 10.0.8.71, origin i, localpref 100, metric 0, originator 208.209.251.247, clusterlist 0.0.0.1, path , community , extended community
007473: Jun 30 12:28:14.587 EDT: BGP(0): 10.1.1.2 rcv UPDATE about 10.7.1.0/24 — DENIED due to: reflected from the same cluster;

Contributors