CCIE Security Chronicle

What's Next

2009-03-27T08:11:00.000-07:00

I read that you could get the CCIE Service Provider in a month with a CCIE Routing and Switching background. And this is exactly what I want to do next: get the CCIE SP in a month! Service Provider is good to get since it is very useful for the CCDE Practical Exam which is my next goal. Currently there are only 3 CCDEs, so my goal is to be among the first 100 people.

Service Provider Lab blue print can be found here: http://www.cisco.com/web/learning/le3/ccie/sp/lab_exam_blueprint.html
Some good information on the SP lab from the Cisco Learning Network

Code Red

2009-03-13T09:40:00.000-07:00

Code Red Example

i. Marking traffic
Router(config)#class−map match−any http−hacks
Router(config−cmap)#match protocol http url "*default.ida*"
Router(config−cmap)#match protocol http url "*cmd.exe*"
Router(config−cmap)#match protocol http url "*root.exe*"
Router(config)#policy−map mark−inbound−http−hacks
Router(config−pmap)#class http−hacks
Router(config−pmap−c)#set ip dscp 1
Router(config)#interface serial 0/0
Router(config−if)#service−policy input mark−inbound−http−hacks
ii. ACL to drop traffic
Router(config)#access−list 105 deny ip any any dscp 1
Router(config)#access−list 105 permit ip any any
Router(config)#interface ethernet 0/1
Router(config−if)#ip access−group 105 out
iii. PBR to drop traffic
Router(config)#access−list 106 permit ip any any dscp 1
Router(config)#route−map null_policy_route 10
Router(config−route−map)#match ip address 106
Router(config−route−map)#set interface Null0
Router(config)#interface serial 0/0
Router(config−if)#ip policy route−map null_policy_route
iv. Class-Based Policing to drop traffic
Router(config)#policy−map drop−inbound−http−hacks
Router(config−pmap)#class http−hacks
Router(config−pmap−c)#police 1000000 31250 31250
conform−action drop exceed−action drop violate−action drop
Router(config)#interface serial 0/0
Router(config−if)#service−policy input drop−inbound−http−hacks

ASA Cut-Through Proxy

2009-03-13T07:54:00.000-07:00

From the notes given to me by Rob Chee...

Configure authentication using TACACS+

Aaa-server RAD protocol tacacs
Aaa-server RAD (outside) host 192.168.137.10
Key cisco

Configure login prompt:

auth-prompt prompt Enter Your Authentication
auth-prompt accept You are Good
auth-prompt reject Goodbye

Through traffic authentication – This is the default mechanism for authentication. When a user attempts to access a HTTP, HTTPS, FTP, or telnet resource behind the PIX, the PIX redirects users to an authentication page if the traffic matches the cut-through proxy ACL.

Using Telnet

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 23
Access-list AUTH permit tcp any host 192.l68.137.2 eq 23
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD

Using Encryption for HTTP

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 80
Access-list AUTH permit tcp any host 192.l68.137.2 eq 80
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD
Aaa authentication secure-http-client

Using HTTPS

Static (inside,outside) 192.1681.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 443
Access-list AUTH permit tcp any host 192.l68.137.2 eq 443
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RAD

The authentication listener mechanism is the recommended method of authentication. With the basic configuration, a user must access a specific URL on the PIX to authenticate. Since it relies on accessing a URL, only the HTTP and HTTPS authentication methods are supported for this mechanism.

Static (inside,outside) 192.1681.137.2 10.100.100.2
aaa authentication match AUTH outside RAD
aaa accounting match AUTH outside RAD
aaa authentication listener HTTPS outside port HTTPS redirect
aaa authentication listener HTTP outside port HTTP redirect

Authenticate against a virtual IP address, configured on the PIX, through HTTP, HTTPS, and Telnet by redirecting to the virtual IP address when they try to access a resource, through the PIX, that matches the cut-through proxy ACL.

Virtual HTTP 192.168.137.20
Virtual Telnet 192.168.137.20

Static (inside,outside) 192.168.137.2 10.100.100.2
Access-list OUTSIDE permit tcp any host 192.168.137.20 eq 80
Access-list OUTSIDE permit tcp any host 192.168.137.2 eq 80
Access-list AUTH permit tcp any host 192.168.137.20 eq 80
Access-list AUTH permit tcp any host 192.168.137.2 eq 80
Access-group OUTSIDE in interface outside
Aaa authentication match AUTH outside RADIUS
! If secure authentication to the PIX is required
Aaa authentication secure-HTTP-client

With RADIUS, authentication and authorization are bound together. This means that verifying authentication and providing authorization are handled during the same negotiation when a user logs in. It also means that no further authorization privileges can be granted after the login.

When RADIUS is used for PIX cut-through proxy, the ACS server provides downloadable ACLs as authorization. This downloadable ACL becomes a temporary ACL that is created on the PIX with a dynamically created name. This ACL can be viewed with “show access-list” after successful authentication. Below is an example of this.

access-list #ACSACL#-IP-cutthroughproxy-47b78823; 3 elements (dynamic)
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 1 extended permit tcp any host 192.168.137.2 eq telnet (hitcnt=0) 0x78ea2fad
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 2 extended permit tcp any host 192.168.137.2 eq www (hitcnt=0) 0x4519be9a
access-list #ACSACL#-IP-cutthroughproxy-47b78823 line 3 extended permit tcp any host 192.168.137.2 eq https (hitcnt=5) 0x0c281b01

RADIUS Downloadable ACL Authorization

access-list OUTSIDE extended permit udp host 192.168.137.10 eq radius host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq radius-acct host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq 1812 host 192.168.137.8
access-list OUTSIDE extended permit udp host 192.168.137.10 eq 1813 host 192.168.137.8
access-list AUTH extended permit tcp any any eq www
access-list AUTH extended permit tcp any any eq HTTPS
access-list AUTH extended permit tcp any any eq Telnet
static (inside,outside) 192.168.137.2 10.100.100.2 netmask 255.255.255.255
access-group OUTSIDE in interface outside per-user-override
aaa-server RADIUS protocol radius
aaa-server RADIUS (outside) host 192.168.137.10
key cisco
aaa authentication match AUTH outside RADIUS
aaa accounting match AUTH outside RADIUS
aaa authentication listener HTTPS outside port HTTPS redirect
auth-prompt prompt Enter Lab Authentication
auth-prompt accept You're In
auth-prompt reject You're Out

TACACS+ Authorization

access-list OUTSIDE extended permit tcp host 192.168.137.10 eq tacacs host 192.168.137.8
access-list AUTH extended permit tcp any any eq www
access-list AUTH extended permit tcp any any eq HTTPS
access-list AUTH extended permit tcp any any eq Telnet
static (inside,outside) 192.168.137.2 10.100.100.2 netmask 255.255.255.255
access-group OUTSIDE in interface outside
aaa-server TAC protocol tacacs
aaa-server TAC (outside) host 192.168.137.10
key cisco
aaa authentication match AUTH outside TAC
aaa authorization match AUTH outside TAC
aaa accounting match AUTH outside TAC
aaa authentication listener HTTPS outside port HTTPS redirect
auth-prompt prompt Enter Lab Authentication
auth-prompt accept You're In
auth-prompt reject You're Out

PPTP

2009-03-05T07:46:00.000-08:00

http://www.cisco.com/en/US/tech/tk82/tk36/technologies_configuration_example09186a00801e51e2.shtml

Server Side 880W Router:

vpdn enable
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
ip local pool netcraftsmen 192.168.1.1 - 192.168.1.10
!
interface virtual-template 1
encapsulation ppp
peer default ip address pool netcraftsmen
ip unnumbered FastEthernet4
ppp encrypt mppe auto
ppp authentication pap chap

Remote Trigger Black Hole Filtering

2009-03-03T11:19:00.000-08:00

Cisco has a real good document on this: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd80313fac.pdf

It is a technique used to drop bad packets before they get into the network: used for DDOS attack mitigation.
interface Null0
no ip unreachables
!When packet is dropped, an Internet Control Message Protocol (ICMP) unreachable message is !sent back to the source. So it is recommended that ICMP unreachable message is disabled.
!
router bgp 65535
neighbor IBGP peer-group
neighbor IBGP remote-as 701
neighbor IBGP send-community
neighbor IBGP update-source Loopback0
neighbor 1.1.1.1 peer-group IBGP
neighbor 2.2.2.2 peer-group IBGP
!
redistribute static route-map STATIC_TO_BGP
!
! A /32 route used as next-hop to “drop” the packets configured on all routers.
!
ip route 192.0.2.1 255.255.255.255 null0
!
! Route-map to signal RTHB information.
!
route-map STATIC_TO_BGP permit 10
match tag 100
set local-preference 200
set origin igp
set community no-export
set ip next-hop 192.0.2.1
!
route-map STATIC_TO_BGP deny 20

When we know that some server, for example 10.10.10.10, under attack, we would put in the blackhole route on the trigger router and propagate to all edge routers which would drop packets at the edge of the network.
!
ip route 10.10.10.10 255.255.255.255 null0 tag 100

Back scatter analysis could be use to trace back the source of the DDOS attack.
Remove the no ip unreachable from the null0 interface on all the edge routers.
Then from the "sinkhole" router:
Add new route-map entry, to propagate self-originated "interesting" routes.
!
route-map STATIC_TO_BGP permit 15
match tag 200
set local-preference 200
set origin igp
set community no-export
!
ip route 20.0.0.0 255.0.0.0 Null0 tag 200
!Network 20.0.0.0/8 is suspected to be the source of the attack. All ICMP unreachable !messages from the edge routers will be diverted to the sinkhole router for analysis.
!
ip access-list extended UNREACHABLES
permit icmp any any unreachable log
permit ip any any
!
interface WAN
ip access-group UNREACHABLES in

If the rate is big, you might not be able to see all logging line. To tune the ACL too log every hit:
ip access-list log-update threshold 1

Count down to March 24, 200

2009-02-22T17:51:00.000-08:00

I am taking the CCIE Security Lab in RTP on March 24, 2009 which is 4 weeks away. When it's a few months away, you felt like you have lots of time on your hand. But when it's around the corner, you start to feel the pressure building and building and BUILDING!

I will try my best to pass. Failing is okay as long as you try your very best and won't have any regrets or doubts that you could have done a better job.
I need to plan on what to do and have to stick to the schedule.

I set up the VPN concentrator with a public IP address. By the end of February, hopefully I will check it off my to-do list.

The Cisco ASA in CCIE Security Lab

2008-10-27T12:04:00.000-07:00

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

GET VPN

2008-10-24T05:48:00.000-07:00

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

2008-10-24T05:41:00.000-07:00

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#

DMVPN with NHRP

2008-10-20T08:00:00.000-07:00

Basic DMVPN overview

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

2008-10-20T07:51:00.000-07:00

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

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

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

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

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

2008-10-20T07:49:00.000-07:00

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

Identify and Mitigate Network Attacks for the CCIE Security Lab Exam

2008-10-17T09:27:00.000-07:00

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:

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]

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

New CCIE Security Lab Exam Blueprint v3.0

2008-10-17T08:55:00.000-07:00

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.

T1 Circuit Problem...

2008-10-14T07:53:00.001-07:00

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.

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.

3750 Stack Weirdness...

2008-10-03T13:00:00.000-07:00

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".

CCIE Security Chronicle

What's Next

Code Red

ASA Cut-Through Proxy

PPTP

Remote Trigger Black Hole Filtering

Count down to March 24, 200

The Cisco ASA in CCIE Security Lab

GET VPN

Identity

Rekeying

Anti-Replay

Counter-based

Time-based

IKE Phase 1 Policy Commands using preshared key

DNS Exploit

Syslog Identification

DMVPN with NHRP

Route Reflector

BGP session through Cisco ASA

Identify and Mitigate Network Attacks for the CCIE Security Lab Exam

New CCIE Security Lab Exam Blueprint v3.0

T1 Circuit Problem...

Line Code Violations

Path Code Violations

Line Errored Seconds (LES)

Slip Seconds

Errored Seconds (ES)

Bursty Errored Seconds (BES)

Severely Errored Seconds (SES)

Severely Errored Framing Second (SEFS)

Degraded Minutes

Unavailable Seconds (UAS)

Other Problems

3750 Stack Weirdness...