Monday October 27th, 2008...
Basic Initialization
hostname ASA1
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 1.1.1.1 255.255.255.0
logging console warnings
logging trap debugging
logging host inside 10.1.1.100
logging enable
Access Management
telnet 10.1.1.100 255.255.255.255 inside
ssh 10.1.1.0 255.255.255.0 outside
ssh timeout 5
Address Translation
access-list NONAT extended permit ip host 8.8.8.8 host 4.4.4.4
global (outside) 1 65.1.200.21-65.1.200.25 netmask 255.255.255.0
nat (inside) 0 access-list NONAT
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) 65.1.15.251 10.1.1.251 netmask 255.255.255.255 (Access from outside to inside server)
static (outside,inside) 10.1.1.5 65.1.15.5 netmask 255.255.255.255 (Access from inside to outside server)
ACLs
Firewall transparent (transparent firewall mode)
access-list OUTSIDE extended permit eigrp host 150.100.3.4 any
access-list OUTSIDE extended permit icmp any any
access-list INSIDE extended permit tcp 150.100.3.0 255.255.255.0 any eq www
access-list INSIDE extended permit tcp 150.100.3.0 255.255.255.0 any eq https
access-list INSIDE extended permit tcp 150.100.3.0 255.255.255.0 any eq telnet
access-list INSIDE extended permit eigrp host 150.100.3.254 any
access-list INSIDE extended permit icmp any any
access-list INSIDE extended permit udp 150.100.3.0 255.255.255.0 any eq domain
access-group OUTSIDE in interface outside
access-group INSIDE in interface inside
IP Routing
route outside 0.0.0.0 0.0.0.0 192.1.12.2 1
route inside 10.3.3.0 255.255.255.0 10.2.2.5 1
router rip
network 65.0.0.0
network 192.168.6.0
passive-interface default
no passive-interface outside
no passive-interface inside
version 2
router ospf 1
network 65.1.15.101 255.255.255.255 area 2
router-id 11.11.11.11
log-adj-changes
default-information originate always
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 65.1.15.101 255.255.255.0
ospf message-digest-key 1 md5
ospf authentication message-digest
Object Groups
object-group protocol PROTOS
protocol-object gre
object-group icmp-type ICMP_ECHO
icmp-object echo
icmp-object echo-reply
object-group service MGMT_PORTS tcp
port-object eq telnet
port-object eq ssh
access-list OUTSIDE extended permit icmp any any object-group ICMP_ECHO
access-list OUTSIDE extended permit tcp any any object-group MGMT_PORTS
access-list OUTSIDE extended permit object-group PROTOS any any
!
access-group OUTSIDE in interface outside
VLANs
interface Ethernet0/0.55
vlan 55
nameif DMZ55
security-level 50
ip address 192.168.5.10 255.255.255.0 standby 192.168.5.11
!
interface Ethernet0/2
!
interface Ethernet0/2.10
description LAN Failover Interface
vlan 550
!
interface Ethernet0/2.20
description STATE Failover Interface
vlan 560
AAA
aaa-server TAC protocol tacacs+
aaa-server TAC host 10.1.1.100
key ipexpert
aaa authentication telnet console TAC
aaa authentication include telnet inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TAC
aaa authentication include http inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TAC
aaa authentication include telnet outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TAC
aaa authentication include tcp/4515 inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TAC
aaa-server RAD protocol radius
aaa-server RAD (dmz) host 10.1.200.251
key cisco
aaa authentication telnet console RAD LOCAL
aaa accounting telnet console RAD
telnet 10.1.33.3 255.255.255.255 inside
VPNs
crypto ipsec transform-set MYTRANS esp-3des esp-sha-hmac
crypto map MYMAP 10 match address L2L
crypto map MYMAP 10 set connection-type answer-only
crypto map MYMAP 10 set peer 192.1.12.15
crypto map MYMAP 10 set transform-set MYTRANS
crypto map MYMAP interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group 192.1.12.15 type ipsec-l2l
tunnel-group 192.1.12.15 ipsec-attributes
pre-shared-key *
access-list L2L extended permit ip host 192.1.49.55 10.1.1.0 255.255.255.0
EZVPN
group-policy EZGroup internal
group-policy EZGroup attributes
wins-server value 10.2.2.175
dns-server value 10.2.2.175
vpn-idle-timeout 30
default-domain value ipexpert.net
username cisco password 3USUcOPFUiMCO4Jk encrypted
crypto ipsec transform-set MYTRANSFORM esp-des esp-md5-hmac
crypto dynamic-map MYDYN 5 set transform-set MYTRANSFORM
crypto map MYMAP 50 ipsec-isakmp dynamic MYDYN
crypto map MYMAP interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group EZGroup type ipsec-ra
tunnel-group EZGroup general-attributes
address-pool MYpool
default-group-policy EZGroup
tunnel-group EZGroup ipsec-attributes
pre-shared-key *
WebVPN
http server enable
http redirect outside 80
webvpn
enable outside
username lab2 password cisco encrypted
Filtering
filter java 80 10.1.11.0 255.255.255.0 10.1.5.0 255.255.255.0
filter java 8080 10.1.11.0 255.255.255.0 10.1.5.0 255.255.255.0
filter activex 80 10.1.11.0 255.255.255.0 10.1.5.0 255.255.255.0
filter activex 8080 10.1.11.0 255.255.255.0 10.1.5.0 255.255.255.0
Failover
Active/Standby
ASA1
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 65.1.15.101 255.255.255.0 standby 65.1.15.102
no shut
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 150.100.1.101 255.255.255.0 standby 150.100.1.102
no shut
!
interface GigabitEthernet0/3
description STATE Failover Interface
no shut
!
interface Management0/0
description LAN Failover Interface
no shut
failover lan unit primary
failover lan interface FAILOVER_LAN Management0/0
failover key luan
failover replication http
failover link STATEFUL_LAN GigabitEthernet0/3
failover interface ip FAILOVER_LAN 1.1.1.1 255.255.255.252 standby 1.1.1.2
failover interface ip STATEFUL_LAN 1.1.1.5 255.255.255.252 standby 1.1.1.6
failover
ASA2:
failover
failover lan unit secondary
failover lan interface FAILOVER_LAN Management0/0
failover key luan
failover interface ip FAILOVER_LAN 1.1.1.1 255.255.255.252 standby 1.1.1.2
Layer 2 Transparent Firewall
firewall transparent
interface GigabitEthernet0/0.3
vlan 31
!
interface GigabitEthernet0/0.33
vlan 32
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/1.3
vlan 311
!
interface GigabitEthernet0/1.33
vlan 321
context custa
allocate-interface GigabitEthernet0/0.3
allocate-interface GigabitEthernet0/1.3
config-url disk0:/custa.cfg
!
context custb
allocate-interface GigabitEthernet0/0.33
allocate-interface GigabitEthernet0/1.33
config-url disk0:/custb.cfg
ip address 65.1.201.103 255.255.255.0 - Need IP address for L2 Transparent Firewall to work
Security Contexts (Virtual Firewall)
context custa
allocate-interface GigabitEthernet0/0
allocate-interface GigabitEthernet0/1
allocate-interface GigabitEthernet0/2
config-url disk0:/custa.cfg
!
context custb
allocate-interface GigabitEthernet0/0
allocate-interface GigabitEthernet0/1
allocate-interface GigabitEthernet0/3
config-url disk0:/custb.cfg
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 65.1.99.101 255.255.255.0
!
interface GigabitEthernet0/1
nameif dmz
security-level 50
ip address 10.1.1.101 255.255.255.0
!
interface GigabitEthernet0/2
nameif inside
security-level 100
ip address 10.1.101.101 255.255.255.0
custa-context
global (outside) 1 interface
global (dmz) 2 interface
nat (inside) 1 0.0.0.0 0.0.0.0
nat (outside) 2 access-list DMZ outside
static (dmz,outside) 65.1.99.253 10.1.1.253 netmask 255.255.255.255
static (dmz,outside) 65.1.99.251 10.1.1.251 netmask 255.255.255.255
access-list DMZ extended permit ip any host 65.1.99.253
access-list DMZ extended permit ip any host 65.1.99.251
route outside 0.0.0.0 0.0.0.0 65.1.99.6 1
access-list OUTSIDE extended permit icmp any any
access-list OUTSIDE extended permit tcp any host 65.1.99.253 eq www
access-list OUTSIDE extended permit udp any host 65.1.99.253 eq ntp
access-list OUTSIDE extended permit tcp any host 65.1.99.251 eq tacacs
access-list OUTSIDE extended permit udp any host 65.1.99.251 eq radius
access-list OUTSIDE extended permit udp any host 65.1.99.251 eq radius-acct
access-group OUTSIDE in interface outside
custb-context
access-list OUTSIDE extended permit icmp any any
access-list OUTSIDE extended deny ip any any log
access-list INSIDE extended permit tcp 10.1.101.0 255.255.255.0 host 6.6.6.6 eq www
access-list INSIDE extended permit icmp any any
access-group OUTSIDE in interface outside
access-group INSIDE in interface inside
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 65.1.99.6 1
Modular Policy Framework
class-map FTP
match port tcp eq ftp
class-map inspection_default
match default-inspection-traffic
class-map VOIP-SIG
match dscp af31
class-map VOIP-DATA
match dscp ef
policy-map VOIP-FTP
class VOIP-DATA
priority
class VOIP-SIG
priority
class FTP
police input 1000000 32000
service-policy VOIP-FTP interface outside
priority-queue outside
Application-Aware Inspection
High Availability Scenarios
QoS Policies
class-map class_ftp
match port tcp eq 2021
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
class class_ftp
inspect ftp
!
service-policy global_policy global
Other Advanced Features
arp outside 10.5.5.5 0012.8031.e118
arp inside 10.5.5.100 0003.6beb.1360
arp timeout 14400
MAC Aging
mac-address-table static outside 0012.8031.e118
mac-address-table static inside 0003.6beb.1360
ARP Spoofing
arp-inspection outside enable no-flood
arp-inspection inside enable no-flood
BGP passthrough
access-list OUTSIDE extended permit tcp host 10.1.11.1 host 10.1.11.254 eq bgp
static (inside,outside) 10.1.11.254 150.100.1.254 netmask 255.255.255.255
static (outside,inside) 150.100.1.1 10.1.11.1 netmask 255.255.255.255
access-group OUTSIDE in interface outside
Deny/Inspect SNMP
snmp-map NO_SNMP_V1
deny version 1
policy-map global_policy
inspect snmp NO_SNMP_V1
Monday, October 27, 2008
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.
Key Server
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
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:
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
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
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.
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
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;
BGP session through Cisco ASA
You can configure MD5 authentication between two BGP peers, which means that each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them will not be made. The configuration of MD5 authentication causes Cisco IOS software to generate and check the MD5 digest of every segment sent on the TCP connection. If authentication is invoked and a segment fails authentication, then an error message will be displayed in the console.
When you are configuring BGP peers with MD5 authentication that pass through a PIX firewall, it is important to configure the PIX between the BGP neighbors so that the sequence numbers for the TCP flows between the BGP neighbors are not random. This is because the TCP random sequence number feature on the PIX firewall is enabled by default, and it changes the TCP sequence number of the incoming packets before it forwards them.
MD5 authentication is applied on the TCP psuedo-IP header, TCP header and data (refer to RFC 2385). TCP uses this data—which includes the TCP sequence and ACK numbers—along with the BGP neighbor password to create a 128 bit hash number. The hash number is included in the packet in a TCP header option field. By default, the PIX offsets the sequence number by a random number, per TCP flow. On the sending BGP peer, TCP uses the original sequence number to create the 128 bit MD5 hash number and includes this hash number in the packet. When the receiving BGP peer gets the packet, TCP uses the PIX-modified sequence number to create a 128 bit MD5 hash number and compares it to the hash number that is included in the packet.
The hash number is different because the TCP sequence value was changed by the PIX, and TCP on the BGP neighbor drops the packet and logs an MD5 failed message.
R2–65.1.200.2—–ASA——-65.1.4.4—–R4
ASA CONFIGURATION: (extra norandomseq)
access-list OUTSIDE extended permit tcp any any eq bgp log
tcp-map BGP
tcp-options range 19 19 allow
static (inside,outside) 65.1.4.2 65.1.200.2 netmask 255.255.255.255 norandomseq
static (outside,inside) 65.1.200.4 65.1.4.4 netmask 255.255.255.255 norandomseq
access-group OUTSIDE in interface outside
class-map BGP
match port tcp eq bgp
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
service-policy global_policy global
The BGP session is fine without password. As soon as enter the command neighbor x.x.x.x password cisco, thing not working.
DEBUG IP TCP TRANSACTION ON ROUTER:
*Jul 2 04:56:53.451: BGP: 65.1.4.2 open active, local address 65.1.4.4
*Jul 2 04:56:53.451: TCB66151E74 created
*Jul 2 04:56:53.451: TCB66151E74 setting property TCP_WINDOW_SIZE (0) 6615C160
*Jul 2 04:56:53.451: TCB66151E74 setting property TCP_MD5KEY (5) 66002A00
*Jul 2 04:56:53.451: TCB66151E74 setting property TCP_TOS (11) 6615C140
*Jul 2 04:56:53.451: TCB66151E74 setting property TCP_OUT_TTL (24) 66150EFA
*Jul 2 04:56:53.451: TCP: Random local port generated 27487, network 0
*Jul 2 04:56:53.451: TCB66151E74 bound to 65.1.4.4.27487
*Jul 2 04:56:53.451: Reserved port 27487 in Transport Port Agent for TCP IP type 1
*Jul 2 04:56:53.451: TCP: sending SYN, seq 1925459762, ack 0
*Jul 2 04:56:53.451: TCP0: Connection to 65.1.4.2:179, advertising MSS 1440
*Jul 2 04:56:53.451: TCP0: state was CLOSED -> SYNSENT [27487 -> 65.1.4.2(179)]
*Jul 2 04:56:55.451: 65.1.4.4:27487 <—> 65.1.4.2:179 congestion window changes
*Jul 2 04:56:55.451: cwnd from 1440 to 1440, ssthresh from 65535 to 2880
*Jul 2 04:56:55.451: TCP0: timeout #1 - timeout is 4000 ms, seq 1925459762
*Jul 2 04:56:55.451: TCP: (27487) -> 65.1.4.2(179)
*Jul 2 04:56:59.451: TCP0: timeout #2 - timeout is 8000 ms, seq 1925459762
*Jul 2 04:56:59.451: TCP: (27487) -> 65.1.4.2(179)
*Jul 2 04:57:00.907: %TCP-6-BADAUTH: Invalid MD5 digest from 65.1.4.2(12644) to 65.1.4.4(179)
*Jul 2 04:57:00.907: TCP0: bad seg from 65.1.4.2 — Invalid MD5 string: port 179 seq 1857634658 ack 0 rcvnxt 0 rcvwnd 16384 len 0
*Jul 2 04:57:07.451: TCP: (27487) -> 65.1.4.2(179)
*Jul 2 04:57:23.451: TCP0: state was SYNSENT -> CLOSED [27487 ->65.1.4.2(179)]
*Jul 2 04:57:23.451: Released port 27487 in Transport Port Agent for TCP IP type 1 delay 240000
*Jul 2 04:57:23.451: TCB 0×66151E74 destroyed
*Jul 2 04:57:23.451: BGP: 65.1.4.2 open failed: Connection timed out; remote host not responding, open active delayed 29552ms (35000ms max, 28% jitter)
The right way is not to NAT! Use static identity NAT or no nat-control.
access-list BGP-MD5-ACL remark *** Allow BGP MD5 Authentication ****
access-list BGP-MD5-ACL permit tcp host 172.16.13.4 host 172.16.11.1 eq bgp
!— Access list allows BGP traffic to pass from outside to inside.
access-group BGP-MD5-ACL in interface outside
tcp-map BGP-MD5
tcp-options range 19 19 allow
!
class-map BGP-MD5-CLASSMAP
match access-list BGP-MD5-ACL
!
policy-map global_policy
class BGP-MD5-CLASSMAP
set connection advanced-options BGP-MD5
set connection random-sequence-number disable
service-policy global_policy global
Friday, October 17, 2008
Identify and Mitigate Network Attacks for the CCIE Security Lab Exam
1. Fragmentation attacks
Typically, a network-forwarding device such as a router or switch does not reassemble the fragmented packets that it receives. Usually the destination host reconstructs the fragmented packets when they all arrive. However, passing fragmented packets through a firewall is insecure. An attacker can intentionally break up packets to conceal traffic strings that the firewall otherwise would detect and block and use fragmented packets for DOS attacks. To combat this, any non-initial fragment will be discarded unless the corresponding initial fragment was permitted to pass through the firewall. Non-initial fragments received before the corresponding initial fragments will be discarded. This eliminates the possibility of overloading host resources with unmatched non-initial fragments, and requires attackers to use relatively elaborate address spoofing for attacks using unmatched initial fragments.
On Cisco router, starting at 12.3.8T, the Virtual Fragmentation Reassembly feature helps protect against various fragmentation attacks.
Using the ACL is shown here: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800949b8.shtml
Look at the example closely to have a better understanding:
2. Malicious IP option usage
3. Network reconnaissance attacks
4. IP spoofing attacks
5. MAC spoofing attacks
6. ARP spoofing attacks
7. Denial of Service (DoS) attacks
8. Distributed Denial of Service (DDoS) attacks
There is a good article here: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html on DDOS. Since this article focus on the CCIE Lab exam hardware and software, I won't go much into the Cisco DDOS Mitigation system using the Cisco Guard XT line of product.
9. Man-in-the-Middle (MiM) attacks
10. Port redirection attacks
11. DHCP attacks
12. DNS attacks
13. Smurf attacks
14. SYN attacks
15. MAC Flooding attacks
16. VLAN hopping attacks
17. Layer2 and Layer3 attacks
Typically, a network-forwarding device such as a router or switch does not reassemble the fragmented packets that it receives. Usually the destination host reconstructs the fragmented packets when they all arrive. However, passing fragmented packets through a firewall is insecure. An attacker can intentionally break up packets to conceal traffic strings that the firewall otherwise would detect and block and use fragmented packets for DOS attacks. To combat this, any non-initial fragment will be discarded unless the corresponding initial fragment was permitted to pass through the firewall. Non-initial fragments received before the corresponding initial fragments will be discarded. This eliminates the possibility of overloading host resources with unmatched non-initial fragments, and requires attackers to use relatively elaborate address spoofing for attacks using unmatched initial fragments.
On Cisco router, starting at 12.3.8T, the Virtual Fragmentation Reassembly feature helps protect against various fragmentation attacks.
Using the ACL is shown here: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800949b8.shtml
Look at the example closely to have a better understanding:
access-list 101 deny ip any host 171.16.23.1 fragments
access-list 101 permit tcp any host 171.16.23.1 eq 80
access-list 101 deny ip any any
ACL 101 does not allow non-initial fragments through to the server because of the first line. A non-initial fragment to the server is denied when it encounters the first ACL line because the Layer 3 information in the packet matches the Layer 3 information in the ACL line.
Initial or non-fragments to port 80 on the server also match the first line of the ACL for Layer 3 information, but because the fragments keyword is present, the next ACL entry (the second line) is processed. The second line of the ACL permits the initial or non-fragments because they match the ACL line for Layer 3 and Layer 4 information.
Non-initial fragments destined to the TCP ports of other hosts on the 171.16.23.0 network are blocked by this ACL. The Layer 3 information in these packets does not match the Layer 3 information in the first ACL line, so the next ACL line is processed. The Layer 3 information in these packets does not match the Layer 3 information in the second ACL line either, so the third ACL line is processed. The third line is implicit and denies all traffic.
ACL 101 permits only non-fragmented HTTP flows to the server
By default, the Cisco ASA allows up to 24 fragments per IP packet, and up to 200 fragments awaiting reassembly. To set disallow fragments, enter the following command:
ASA1(config)# fragment chain 1 [interface_name]
3. Network reconnaissance attacks
4. IP spoofing attacks
5. MAC spoofing attacks
6. ARP spoofing attacks
7. Denial of Service (DoS) attacks
8. Distributed Denial of Service (DDoS) attacks
There is a good article here: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html on DDOS. Since this article focus on the CCIE Lab exam hardware and software, I won't go much into the Cisco DDOS Mitigation system using the Cisco Guard XT line of product.
9. Man-in-the-Middle (MiM) attacks
10. Port redirection attacks
11. DHCP attacks
12. DNS attacks
13. Smurf attacks
14. SYN attacks
15. MAC Flooding attacks
16. VLAN hopping attacks
17. Layer2 and Layer3 attacks
New CCIE Security Lab Exam Blueprint v3.0
http://www.cisco.com/web/learning/le3/ccie/security/lab_exam_blueprint_v3.html
Newer OSes mean more features to look at such as Zone Base Firewall, GET VPN. Though, I don't know how they are going to sneak in GET VPN into the lab? Normally, people associate GET VPN with MPLS, does that mean Cisco will replace the Frame-Relay backbone with MPLS??? I seriously doubt it, it just means that Cisco will put GET VPN over the Frame-Relay.
For a comparison of Cisco VPN solution: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps7180/prod_brochure0900aecd80582078.pdf
Cisco doesn't seem to have a place for all the security exploits they have on the exam, at least I am not aware of one. I usually have the Juniper Netscreen documentation for Attacks Detection and Defense Mechanisms page handy for reference.
Newer OSes mean more features to look at such as Zone Base Firewall, GET VPN. Though, I don't know how they are going to sneak in GET VPN into the lab? Normally, people associate GET VPN with MPLS, does that mean Cisco will replace the Frame-Relay backbone with MPLS??? I seriously doubt it, it just means that Cisco will put GET VPN over the Frame-Relay.
For a comparison of Cisco VPN solution: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps7180/prod_brochure0900aecd80582078.pdf
Cisco doesn't seem to have a place for all the security exploits they have on the exam, at least I am not aware of one. I usually have the Juniper Netscreen documentation for Attacks Detection and Defense Mechanisms page handy for reference.
Tuesday, October 14, 2008
T1 Circuit Problem...
We've been having problem with a T1 line for a couple months. Verizon tested the circuit clean from smart jack to smart jack. They could run a loop between their smart jacks. They said they could loop our CSU at one end only, so we thought the problem lies at the other end. We switched out the router, the WIC card, the cable, and even re terminated the extended RJ48X jack. But the circuit would just start bouncing up and down after some hours or a couple of days.
Verizon said that is so because when they are in the circuit testing, they break up the cell signal, so once they are out, the routers could communicate again: claiming it's our equipment that couldn't resync itself!
It is worth noting that our circuit has been working for years and also, there's another T1 circuit using the same VWIC card and it has no problem whatsoever. If there is a problem with the VWIC/WIC cards, then service would be down completely and not just intermittenly.
Verizon then, sent a technician out to test their smart jack and also the extended demark. When you call in to test the circuit, the provider only tested to the front end of the smart jack. Though, they also own the back end of it, they usually don't test to it since it requires a technician to be onsite. So when they do that, they usually will charge you at the discretion of the technician if no problems found.
Again, everything tested good. This time the circuit stayed up much longer than before: 2 days and 18 hours. But then it started bouncing again.
At this time, we are almost out of option. We were clueless to what happen, since everything that could be wrong had been replaced and/or fixed.
But then, persistent in calling Verizon paid off. We talked to a very knowledgable testerl. He pointed out that the rate of the line is at about 17 db which is high. It is supposed to be ~0. This is because both side of the circuit try to become the source of the clocking.
We had one side set to be the source and the other side feed from the line since this is a point to point circuit. The configuration is as follow for the source clocking device:
no network-clock-participate wic 0
controller T1 0/1/1
framing esf
clock source internal
linecode b8zs
channel-group 1 timeslots 1-24
description T1
So, Verizon sent out a technician to replace the smart jack at the clock source end. It didn't help since the rate is still up in the 17 db. But it does make the circuit stay up for a while. If the circuit goes down again, then we will have to make the replace the smart jack at the other end. This comes with a catch: if they don't see any problem with their smart jack, then we will be charged at the discretion of the technician. We are still waiting for the circuit to drop, which it is bound to be since the rate is in the 17 db which means that our equipments' clocking is out of sync with Verizon central office DEC cross connect, and then get authorization for tech dispatching.
Here is a little something about trouble shooting a T1 line, pasted here just for easy access and in case the link will be down in the future.
Verizon said that is so because when they are in the circuit testing, they break up the cell signal, so once they are out, the routers could communicate again: claiming it's our equipment that couldn't resync itself!
It is worth noting that our circuit has been working for years and also, there's another T1 circuit using the same VWIC card and it has no problem whatsoever. If there is a problem with the VWIC/WIC cards, then service would be down completely and not just intermittenly.
Verizon then, sent a technician out to test their smart jack and also the extended demark. When you call in to test the circuit, the provider only tested to the front end of the smart jack. Though, they also own the back end of it, they usually don't test to it since it requires a technician to be onsite. So when they do that, they usually will charge you at the discretion of the technician if no problems found.
Again, everything tested good. This time the circuit stayed up much longer than before: 2 days and 18 hours. But then it started bouncing again.
At this time, we are almost out of option. We were clueless to what happen, since everything that could be wrong had been replaced and/or fixed.
But then, persistent in calling Verizon paid off. We talked to a very knowledgable testerl. He pointed out that the rate of the line is at about 17 db which is high. It is supposed to be ~0. This is because both side of the circuit try to become the source of the clocking.
We had one side set to be the source and the other side feed from the line since this is a point to point circuit. The configuration is as follow for the source clocking device:
no network-clock-participate wic 0
controller T1 0/1/1
framing esf
clock source internal
linecode b8zs
channel-group 1 timeslots 1-24
description T1
So, Verizon sent out a technician to replace the smart jack at the clock source end. It didn't help since the rate is still up in the 17 db. But it does make the circuit stay up for a while. If the circuit goes down again, then we will have to make the replace the smart jack at the other end. This comes with a catch: if they don't see any problem with their smart jack, then we will be charged at the discretion of the technician. We are still waiting for the circuit to drop, which it is bound to be since the rate is in the 17 db which means that our equipments' clocking is out of sync with Verizon central office DEC cross connect, and then get authorization for tech dispatching.
Here is a little something about trouble shooting a T1 line, pasted here just for easy access and in case the link will be down in the future.
DEBUGGING T1
Before troubleshooting any aspect of a connectivity issue (e.g., ISDN, CAS, modem) you should always verify the physical integrity of the T1 line. You should always check the status of the T1 controllers and verify you are not receiving any errors. show controller T1 x will give the snapshot of the T1 physical layer status. There should not be any framing errors, Slips, or line code violations.
Following is the sample output of show controller T1 0 and what to look at:
AS5300#show controllers t1 0
T1 0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
Version info of slot 0: HW: 4, Firmware: 16, PLD Rev: 0
Manufacture Cookie Info:
EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42,
Board Hardware Version 1.32, Item Number 73-2217-5,
Board Revision B16, Serial Number 09356930,
PLD/ISP Version 0.0, Manufacture Date 18-Jun-1998.
Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary.
Data in current interval (8 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
The main items to look at in the above output is
- The status of the line
- Alarms
- Linecode and Pathcode violations
- Slip Secs
The line status will tell us if the T1 is either up, down, or administratively down. The Alarms section is very important and it will tell us what type of problem maybe present on the line. The presence of any alarms indicates a serious problem on the line.
It is recommended whenever you encounter a T1 that is in an alarm state that you verify the framing and linecoding parameters are configured correctly. Please refer to the show controller t1 commands in the Command Reference to find out all the possible values for the alarm state.
A common message you will see in the alarm field is "receiver has loss of frame." Some routers will also report a 'loss of frame' even when it should be a "loss of signal." So, make sure whenever you receive these errors that the T1 signal is present and the framing is correct.
Another message you might receive is "receiver is getting AIS." This means the receiver is getting an alarm indication signal (blue alarm). This is a framed or unframed all-ones signal in both SF and ESF formats transmitted to maintain transmission continuity. This is typically seen when the far-end CSU has lost its terminal side equipment. The "receiver has remote alarm" indicates the presence of a yellow alarm. This means the downstream CSU is in a loss-of-frame or loss-of-signal state. Therefore, the remote CSU has a red alarm.
The "transmitter is sending remote alarm" indicates that the local CSU has detected either a loss-of-frame or loss-of-signal condition. This indicates that the local controller has a red alarm. This message will be accompanied by a "receiver has loss of frame." Always verify framing and T1 signal when troubleshooting this problem.
If any of the above highlighted fields doesn't contain zeros, than here are some of the possibilities what might causing the physical problem. Following is the brief explanation of these fields.
Line Code Violations
Indicates the occurrence of either a Bipolar Violation (BPV) or Excessive Zeros (EXZ) error event.
A BPV error event for an AMI-coded signal is the occurrence of a pulse of the same polarity as the previous pulse.
A BPV error event for a B8ZS is the occurrence of a pulse of the same polarity as the previous pulse without being a part of the zero substitution code. An EXZ is the violation of the pulse density requirement.
Path Code Violations
Indicates a frame synchronization bit error in the D4 and E1-noCRC formats, or a CRC error in the ESF and E1-CRC formats.
Line Errored Seconds (LES)
A Line Errored Second, according to T1M1.3, is a second in which one or more Line Code Violation error events were detected.
In the T1M1.3 specification, near end Line Code Violations and far end Line Errored Seconds are counted. For consistency, we count Line Errored Seconds at both ends.
Slip Seconds
A Controlled Slip Second is a one-second interval containing one or more controlled slips.
Errored Seconds (ES)
For ESF and E1-CRC links an Errored Second is a second with one or more Path Code Violations OR one or more Out of Frame defects OR one or more Controlled Slip events OR a detected AIS defect.
For D4 and E1-noCRC links, the presence of Bipolar Violations also triggers an Errored Second.
This is not incremented during an Unavailable Second.
Bursty Errored Seconds (BES)
A Bursty Errored Second (also known as Errored Second type B) is a second with fewer than 320 and more than 1 Path Coding Violation error events, no Severely Errored Frame defects and no detected incoming AIS defects. Controlled slips are not included in this parameter.
This is not incremented during an Unavailable Second.
Severely Errored Seconds (SES)
A Severely Errored Second for ESF signals is a second with 320 or more Path Code Violation Error Events, one or more Out of Frame defects, or a detected AIS defect.
For E1-CRC signals, a Severely Errored Second is a second with 832 or more Path Code Violation error events or one or more Out of Frame defects.
For E1-noCRC signals, a Severely Errored Second is a 2048 LCVs or more.
For D4 signals, a Severely Errored Second is a count of one-second intervals with Framing Error events, or an OOF defect, or 1544 LCVs or more.
Controlled slips are not included in this parameter. This is not incremented during an Unavailable Second.
Severely Errored Framing Second (SEFS)
An Severely Errored Framing Second is a second with one or more Out of Frame defects or a detected AIS (Alarm Indication Signal) defect.
Degraded Minutes
A Degraded Minute is one in which the estimated error rate exceeds 1E-6 but does not exceed 1E-3 (see G.821 [15]).
Degraded Minutes are determined by collecting all of the Available Seconds, removing any Severely Errored Seconds grouping the result in 60-second long groups and counting a 60-second long group (a.k.a., minute) as degraded if the cumulative errors during the seconds present in the group exceed 1E-6. Available seconds are merely those seconds which are not Unavailable, as described below.
Unavailable Seconds (UAS)
Unavailable Seconds (UAS) are calculated by counting the number of seconds that the interface is unavailable. The DS1 interface is said to be unavailable from the onset of 10 contiguous SESs, or the onset of the condition leading to a failure (see Failure States). If the condition leading to the failure was immediately preceded by one or more contiguous SESs, then the DS1 interface unavailability starts from the onset of these SESs. Once unavailable, and if no failures present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs. Once unavailable, and if a failure is present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, if the failure clearing time is less than or equal to 10 seconds. If the failure clearing time is more than 10 seconds, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, or the onset period leading to the successful clearing condition, whichever occurs later. With respect to the DS1 error counts, all counters are incremented while the DS1 interface is deemed available. While the interface is deemed unavailable, the only count that is incremented is UASs.
Other Problems
Another common problem with T1 troubleshooting are: misconfiguration of Controller T1 and also wrong cabling between AS5300 and the switch.
Make sure that framing and line coding settings are the same for the switch and the AS5300. These physical problems also occur due to the linebeing built out. If the PBX is very close to the AS5300, make sure that signal is not too hot.
Whenever you are troubleshooting a T1, always verify that both-sides of the circuit are running clean. It is possible that only one side of the T1 is seeing errors. Remember, that the T1 is going only between you and the provider. Always contact the provider to make sure they aren't seeing errors on their side of the circuit.
Friday, October 3, 2008
3750 Stack Weirdness...
We upgraded one of our core switch from a 4507R to a 6509-E. While moving a 3750 distribution stack switch connection, we changed the uplink port of the stack from 1/0/25 to 4/0/25 (from switch 1 to switch 4). Switch 2 is the stack master switch.
The strangest thing happened: process CPU shot up to ~90% compare with ~10% as before.
3750_Stack#sho proc cpu | exc 0.00
CPU utilization for five seconds: 88%/15%; one minute: 62%; five minutes: 62%PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
51 11511131023271962 1 0.31% 0.19% 0.24% 0 Fifo Error Detec
81 363750 181272000 2 0.15% 0.03% 0.04% 0 hpm main process
85 4191815 30304200 138 0.31% 0.13% 0.10% 0 hpm counter proc
86 16179917 86606818 186 0.15% 0.08% 0.06% 0 HRPC pm-counters
116 2304082 454784198 5 6.38% 1.71% 1.52% 0 Hulc LED Process
169 17070389 78940409 216 60.54% 42.65% 42.44% 0 IP Input
Where IP Input process CPU Utilization is way off the norm.
Reading up on troubleshooting high CPU on Cisco routers, troubleshooting High CPU Utilization in IP Input Process, troubleshooting high CPU on Catalyst 3750 Series Switches, and supportwiki 3750 high CPU didn't yield any fruitful result.
Further searching on bug tool kit resulted in a bug that has similar description to what we ran into:"Catalyst3750 removes its hardware forwarding information in certain condition. This will result in software forwarding" which explains why our CPU is so high. The suggested work around is to shutdown and bring back up the interface in question. We did that and boom! the process CPU come back down to normal again!
I learned a thing or two about Catalyst 3750 Series Stackwise operation:
Troubleshooting with Stack, and commands such as "show platform..." and "remote command".
The strangest thing happened: process CPU shot up to ~90% compare with ~10% as before.
3750_Stack#sho proc cpu | exc 0.00
CPU utilization for five seconds: 88%/15%; one minute: 62%; five minutes: 62%PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
51 11511131023271962 1 0.31% 0.19% 0.24% 0 Fifo Error Detec
81 363750 181272000 2 0.15% 0.03% 0.04% 0 hpm main process
85 4191815 30304200 138 0.31% 0.13% 0.10% 0 hpm counter proc
86 16179917 86606818 186 0.15% 0.08% 0.06% 0 HRPC pm-counters
116 2304082 454784198 5 6.38% 1.71% 1.52% 0 Hulc LED Process
169 17070389 78940409 216 60.54% 42.65% 42.44% 0 IP Input
Where IP Input process CPU Utilization is way off the norm.
Reading up on troubleshooting high CPU on Cisco routers, troubleshooting High CPU Utilization in IP Input Process, troubleshooting high CPU on Catalyst 3750 Series Switches, and supportwiki 3750 high CPU didn't yield any fruitful result.
Further searching on bug tool kit resulted in a bug that has similar description to what we ran into:"Catalyst3750 removes its hardware forwarding information in certain condition. This will result in software forwarding" which explains why our CPU is so high. The suggested work around is to shutdown and bring back up the interface in question. We did that and boom! the process CPU come back down to normal again!
I learned a thing or two about Catalyst 3750 Series Stackwise operation:
Troubleshooting with Stack, and commands such as "show platform..." and "remote command".
Subscribe to:
Posts (Atom)
