Object groups
An ACL (Access-list), can allow clients, to access particular server for a specific service, as the number of server increases, the number of lines in an ACL increases as well.
let see how to implement security policies, with access-list and how can we simplify the Access-list by the use of object grouping. (by default FW ACL are extendet). lets see the structure of an ACL on the PIX Firewall.
MYPIX(config)# access-list 1 permit ? configure mode commands/options: Enter protocol number (0 - 255) Hostname or A.B.C.D Match based on destination network address ah any Abbreviation for an address and mask of 0.0.0.0 0.0.0.0 eigrp esp gre host Use this keyword to configure destination host icmp icmp6 igmp igrp ip ipinip ipsec nos object-group Specify a service or protocol object-group after this keyword ospf pcp pim pptp snp tcp udp MYPIX(config)# access-list 1 permit tcp ? configure mode commands/options: Hostname or A.B.C.D Source IP address any Abbreviation for source address and mask of 0.0.0.0 0.0.0.0 host Use this keyword to configure source host interface Use interface address as source address object-group Network object-group for source address MYPIX(config)# access-list 1 permit tcp any ? configure mode commands/options: Hostname or A.B.C.D Destination IP address any Abbreviation for destination address and mask of 0.0.0.0 0.0.0.0 eq Port equal to operator gt Port greater than operator host Use this keyword to configure destination host interface Use interface address as destination address lt Port less than operator neq Port not equal to operator object-group Optional service object-group name for source port or <strong>network object-group</strong> for destination address range Port range operator MYPIX(config)# access-list 1 permit tcp any any ? configure mode commands/options: eq Port equal to operator gt Port greater than operator inactive Keyword for disabling an ACL element log Keyword for enabling log option on this ACL element lt Port less than operator neq Port not equal to operator object-group Optional <strong>service object-group</strong> for destination port range Port range operator time-range Keyword for attaching time-range option to this ACL element MYPIX(config)# access-list 1 permit tcp any any ? configure mode commands/options: eq Port equal to operator gt Port greater than operator inactive Keyword for disabling an ACL element log Keyword for enabling log option on this ACL element lt Port less than operator neq Port not equal to operator object-group Optional service object-group for destination port range Port range operator time-range Keyword for attaching time-range option to this ACL element
With Object grouping, we find a way to group object of a similar type so that a single ACL can apply to all the object in the group.
The following types of object group exist:
icmp-type Specifies a group of ICMP types, such as echo
network Specifies a group of host or subnet IP addresses -> is used to group client host, server or subnets.
protocol Specifies a group of protocols, such as TCP, etc -> is used to group protocoles, can contain one of the keywords, icmp, ip, tcp, or upd, or a value between 1 to 254 to represent an IP Protocol Number.
service Specifies a group of TCP/UDP ports/services -> , to group TCP or UDP ports numbers assigned to a different service
Lets do an example on how to use object groups.
First we are going to configurethe access-list, then we are showing how to use the object group.
Connections from low (0 – outside) to high security (1 – inside ) are disallowed unless the configuration explicitly permits them. An access list is applied to an interface and checks all traffic with no difference between the direction of traffic as outbound (high-to-low security) and inbound (low-to-high security), but an ACL is not necesary if going from a higher security level to a lower. everything that is inspected in the global_policy policy-map will be allowed.
policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 _default_h323_map inspect h323 ras _default_h323_map inspect rsh inspect rtsp inspect esmtp _default_esmtp_map inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp class class-default
ok that is working, lets clear the access list, in order to simplify this example using Object Groups.
Now say that we are told that we need to configure our pix to allow users to access the following servers, in a single object.
WWW 2.2.2.1
Syslog 2.2.2.2
FTP 2.2.2.3
Email 2.2.2.4
for the momment we will allow any IP Traffic comming from the outside to access this servers, and the requeriment is to use the least amount of lines in our configuration.
so we can configure:
An object can be a member of a group. For object groups to be nested, they must be of the same type, for example, all networks/hosts, protocols, or services
Finally we have:
Very nice feature Cisco!!
Victor.-
Main(6 messages) or aggressive (3 messages) Mode
Resume of the IKE Phases
Phase 1:
* Authenticate the peers
* Negotiate a bidirectional SA
* Main mode (6 messages) or aggressive mode (3 messages)
** show crypto isakmp sa
Phase 1.5:
* Xauth (User Authentication)
* Mode config (Push Config)
Phase 2:
* IPsec SAs/SPIs
* Quick mode
** show crypto ipsec sa
Main mode:
has three two-way exchanges between the initiator and receiver:
— First exchange—The algorithms and hashes used to secure the IKE communications are negotiated and agreed upon between peers.
— Second exchange—This exchange uses a DH exchange to generate shared secret keys and pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity. The shared secret key is used to generate all the other encryption and authentication keys.
— Third exchange—This exchange verifies the other side’s identity. It is used to authenticate the remote peer. The main outcome of main mode is a secure communication path for subsequent exchanges between the peers. Without proper authentication, you might establish a secure communication channel with a hacker who could be stealing all your sensitive material.
– Takes longer time to negotiate
– Hides party identities performing DH exchange
Initiator Responder
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni, GSSi -->
<-- HDR, KE, Nr, GSSr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
crypto isakmp key cisco123 address 2.2.2.2 ! ! crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac ! crypto map NAME local-address Loopback0 crypto map NAME 10 ipsec-isakmp set peer 2.2.2.2 set transform-set R3R2 match address 100 ! ! ! AKMP: Created a peer struct for 2.2.2.2, peer port 500 ISAKMP: New peer created peer = 0x66F2A5F4 peer_handle = 0x80000004 ISAKMP: Locking peer struct 0x66F2A5F4, refcount 1 for isakmp_initiator ISAKMP: local port 500, remote port 500 ISAKMP: set new node 0 to QM_IDLE ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 66F1F9DC ISAKMP:(0):Can not start Aggressive mode, trying Main mode. ISAKMP:(0):found peer pre-shared key matching 2.2.2.2 ISAKMP:(0): constructed NAT-T vendor-07 ID ISAKMP:(0): constructed NAT-T vendor-03 ID ISAKMP:(0): constructed NAT-T vendor-02 ID ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1 ISAKMP:(0): beginning Main Mode exchange ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_NO_STATE ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_NO_STATE ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2 ISAKMP:(0): processing SA payload. message ID = 0 ISAKMP:(0): processing vendor id payload ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch ISAKMP (0:0): vendor ID is NAT-T v7 ISAKMP:(0):found peer pre-shared key matching 2.2.2.2 ISAKMP:(0): local preshared key found ISAKMP : Scanning profiles for xauth ... ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy ISAKMP: encryption DES-CBC ISAKMP: hash SHA ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP: life type in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 ISAKMP:(0):atts are acceptable. Next payload is 0 ISAKMP:(0): processing vendor id payload ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch ISAKMP (0:0): vendor ID is NAT-T v7 ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2 ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_SA_SETUP ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3 ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_SA_SETUP ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4 ISAKMP:(0): processing KE payload. message ID = 0 ISAKMP:(0): processing NONCE payload. message ID = 0 ISAKMP:(0):found peer pre-shared key matching 2.2.2.2 ISAKMP:(1002): processing vendor id payload ISAKMP:(1002): vendor ID is Unity ISAKMP:(1002): processing vendor id payload ISAKMP:(1002): vendor ID is DPD ISAKMP:(1002): processing vendor id payload ISAKMP:(1002): speaking to another IOS box! ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE ISAKMP:(1002):Old State = IKE_I_MM4 New State = IKE_I_MM4 ISAKMP:(1002):Send initial contact ISAKMP:(1002):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR ISAKMP (0:1002): ID payload next-payload : 8 type : 1 address : 3.3.3.3 protocol : 17 port : 500 length : 12 ISAKMP:(1002):Total payload length: 12 ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE ISAKMP:(1002):Old State = IKE_I_MM4 New State = IKE_I_MM5 ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH ISAKMP:(1002): processing ID payload. message ID = 0 ISAKMP (0:1002): ID payload next-payload : 8 type : 1 address : 2.2.2.2 protocol : 17 port : 500 length : 12 ISAKMP:(1002):: peer matches *none* of the profiles ISAKMP:(1002): processing HASH payload. message ID = 0 ISAKMP:(1002):SA authentication status: authenticated ISAKMP:(1002):SA has been authenticated with 2.2.2.2 ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/, and inserted successfully 66F2A5F4. ISAKMP:(1002):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH ISAKMP:(1002):Old State = IKE_I_MM5 New State = IKE_I_MM6 ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH ISAKMP: set new node 383677917 to QM_IDLE ISAKMP:(1002): processing HASH payload. message ID = 383677917 ISAKMP:(1002): processing DELETE payload. message ID = 383677917 ISAKMP:(1002):peer does not do paranoid keepalives. ISAKMP:(1002):deleting node 383677917 error FALSE reason "Informational (in) state 1" IPSEC(key_engine): got a queue event with 1 KMI message(s) IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE ISAKMP:(1002):Old State = IKE_I_MM6 New State = IKE_I_MM6 ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE ISAKMP:(1002):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE ISAKMP:(1002):beginning Quick Mode exchange, M-ID of 446518647 ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE ISAKMP:(1002):Node 446518647, Input = IKE_MESG_INTERNAL, IKE_INIT_QM ISAKMP:(1002):Old State = IKE_QM_READY New State = IKE_QM_I_QM1 ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE ISAKMP:(1002):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE ISAKMP:(1002): processing HASH payload. message ID = 446518647 ISAKMP:(1002): processing SA payload. message ID = 446518647 ISAKMP:(1002):Checking IPSec proposal 1 ISAKMP: transform 1, ESP_AES ISAKMP: attributes in transform: ISAKMP: encaps is 1 (Tunnel) ISAKMP: SA life type in secondsISAKMP: SA life duration (basic) of 3600 ISAKMP: SA life type in kilobytes ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 ISAKMP: authenticator is HMAC-MD5 ISAKMP: key length is 192 ISAKMP:(1002):atts are acceptable. IPSEC(validate_proposal_request): proposal part #1 IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2, local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1), remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-aes 192 esp-md5-hmac (Tunnel), lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0 Crypto mapdb : proxy_match src addr : 3.3.3.3 dst addr : 2.2.2.2 protocol : 0 src port : 0 dst port : 0 ISAKMP:(1002): processing NONCE payload. message ID = 446518647 ISAKMP:(1002): processing ID payload. message ID = 446518647 ISAKMP:(1002): processing ID payload. message ID = 446518647 ISAKMP:(1002): Creating IPSec SAs inbound SA from 2.2.2.2 to 3.3.3.3 (f/i) 0/ 0 (proxy 2.2.2.2 to 3.3.3.3) has spi 0x8B6DC3A5 and conn_id 0 lifetime of 3600 seconds lifetime of 4608000 kilobytes outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0 (proxy 3.3.3.3 to 2.2.2.2) has spi 0x83BD1925 and conn_id 0 lifetime of 3600 seconds lifetime of 4608000 kilobytes ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE ISAKMP:(1002):deleting node 446518647 error FALSE reason "No Error" ISAKMP:(1002):Node 446518647, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH ISAKMP:(1002):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE IPSEC(key_engine): got a queue event with 1 KMI message(s) Crypto mapdb : proxy_match src addr : 3.3.3.3 dst addr : 2.2.2.2 protocol : 0 src port : 0 dst port : 0 IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2 IPSec: Flow_switching Allocated flow for sibling 80000003 IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0 IPSEC(create_sa): sa created, (sa) sa_dest= 3.3.3.3, sa_proto= 50, sa_spi= 0x8B6DC3A5(2339226533), sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 3 IPSEC(create_sa): sa created, (sa) sa_dest= 2.2.2.2, sa_proto= 50, sa_spi= 0x83BD1925(2210208037), sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 4 IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 83BD1925
Aggressive mode:
fewer exchanges are done and with fewer packets. The first exchange covers almost all of the steps:
the IKE policy set negotiation; the DH public key generation; a nonce, which the other party signs; and an identity packet, which can be used to verify the identity of the other party via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange.
– Takes less time to negotiate
– Does not hide party identities
Initiator Responder HDR, SA, KE, Ni, IDii, GSSi --> <-- HDR, SA, KE, Nr, IDir, GSSr, HASH_R HDR, HASH_I -->
crypto isakmp policy 10
authentication pre-share
!
crypto isakmp peer address 2.2.2.2
set aggressive-mode password cisco123
set aggressive-mode client-endpoint ipv4-address 3.3.3.3
!
!
crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac
!
crypto map NAME local-address Loopback0
crypto map NAME 10 ipsec-isakmp
set peer 2.2.2.2
set transform-set R3R2
match address 100
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
ip address 10.1.13.3 255.255.255.0
duplex auto
speed auto
crypto map NAME
!
access-list 100 permit ip host 3.3.3.3 host 2.2.2.2
!
!
IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 3.3.3.3, remote= 2.2.2.2,
local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x38875DE9(948395497), conn_id= 0, keysize= 192, flags= 0x0
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 2.2.2.2, peer port 500
ISAKMP: New peer created peer = 0x6678E794 peer_handle = 0x80000007
ISAKMP: Locking peer struct 0x6678E794, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 670BE478
ISAKMP:(0):SA has tunnel attributes set.
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:0): ID payload
next-payload : 13
type : 1
address : 3.3.3.3
protocol : 17
port : 0
length : 12
ISAKMP:(0):Total payload length: 12
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM
ISAKMP:(0):Old State = IKE_READY New State = IKE_I_AM1
ISAKMP:(0): beginning Aggressive Mode exchange
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) AG_INIT_EXCH
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing ID payload. message ID = 0
ISAKMP (0:0): ID payload
next-payload : 10
type : 1
address : 2.2.2.2
protocol : 17
port : 0
length : 12
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): speaking to another IOS box!
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(1003): processing HASH payload. message ID = 0
ISAKMP:(1003):SA authentication status:
authenticated
ISAKMP:(1003):SA has been authenticated with 2.2.2.2
ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/, and inserted successfully 6678E794.
ISAKMP:(1003):Send initial contact
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP:(1003):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(1003):Old State = IKE_I_AM1 New State = IKE_P1_COMPLETE
ISAKMP:(1003):beginning Quick Mode exchange, M-ID of -243305607
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1003):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1003):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP: set new node -689131644 to QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -689131644
ISAKMP:(1003): processing DELETE payload. message ID = -689131644
ISAKMP:(1003):peer does not do paranoid keepalives.
ISAKMP:(1003):deleting node -689131644 error FALSE reason "Informational (in) state 1"
IPSEC(key_engine): got a queue event with 1 KMI message(s)
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -243305607
ISAKMP:(1003): processing SA payload. message ID = -243305607
ISAKMP:(1003):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 3600
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP: authenticator is HMAC-MD5
ISAKMP: key length is 192
ISAKMP:(1003):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2,
local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-aes 192 esp-md5-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
Crypto mapdb : proxy_match
src addr : 3.3.3.3
dst addr : 2.2.2.2
protocol : 0
src port : 0
dst port : 0
ISAKMP:(1003): processing NONCE payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): Creating IPSec SAs
inbound SA from 2.2.2.2 to 3.3.3.3 (f/i) 0/ 0
(proxy 2.2.2.2 to 3.3.3.3)
has spi 0x38875DE9 and conn_id 0
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0
(proxy 3.3.3.3 to 2.2.2.2)
has spi 0x77695521 and conn_id 0
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):deleting node -243305607 error FALSE reason "No Error"
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1003):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
src addr : 3.3.3.3
dst addr : 2.2.2.2
protocol : 0
src port : 0
dst port : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2
IPSec: Flow_switching Allocated flow for sibling 80000004
IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0
IPSEC(create_sa): sa created,
(sa) sa_dest= 3.3.3.3, sa_proto= 50,
sa_spi= 0x38875DE9(948395497),
sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 5
IPSEC(create_sa): sa created,
(sa) sa_dest= 2.2.2.2, sa_proto= 50,
sa_spi= 0x77695521(2003391777),
sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 6
IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 77695521
VRF – VPN4 Troubleshooting
Before you start MPLS VPN troubleshooting, you should ask the following questions:
1.- Is Cisco Express Forwarding (CEF) enabled on all routers in the transit path between the provider edge (PE) routers?
You can verify the validity of the CEF entry and the associated label stack with the show ip cef vrf vrf-name ip-prefix detail command. The top label in the stack should correspond to the BGP next-hop label as displayed by the show mpls forwarding-table command on the ingress router. The second label in the stack should correspond to the label allocated by the egress router.
2.- Are labels for Border Gateway Protocol (BGP) next hops generated and propagated?
3.- Are there any maximum transmission unit (MTU) issues in the transit path ?
4.- Verifying the routing information flow using the checks outlined in the figure
5.- Verifying the data flow, or packet forwarding
6.- Are you including the vrf interface into the MP-BGP process??
The first step is to check the routing information exchange from CE routers to PE routers. you can use the show ip route vrf vrf-name command to verify that the PE router receives customer routes from the CE router.
The CE routes received by the PE router need to be redistributed into Multiprotocol BGP (MP BGP); if you do not do this, the routes will not get propagated to other PE routers.
The CE routes redistributed into MP-BGP need to be propagated to other PE routers.
Verify the correct route propagation using show ip bgp vpnv4 all ip-prefix command on the remote PE router.
Routes sent by the originating PE router might not be received by a remote PE router because of automatic RT-based filters installed on the remote PE router.
Automatic route filters are based on RTs. Verify that the RTs attached to the CE route in the originating PE router match at least one of the RTs configured as import RTs in the VRF on the receiving PE router.
The VPN version 4 (VPNv4) routes received by the PE router have to be inserted into the proper VRF. This insertion can be verified with the show ip route vrf command.
the BGP routes received via MP-BGP and inserted into the VRF need to be redistributed into the PE-CE routing protocol. A number of common redistribution mistakes can occur here, starting with missing redistribution metrics.
The routes redistributed into the PE-CE routing protocol have to be propagated to CE routers. You may also configure the CE routers with a default route toward the PE routers.
On Mon, Jun 22, 2009 at 9:36 PM, Dayaa Al Zoubi <cciecool@gmail.com> wrote:
hi
two different bgp areas means two different sp , the VPN4 connectivity
between them , in the border router sh ip route will not show the customer
routes , sh ip bgp vpn4 all will show , but when pinging from the customer
vrf in sp 1 to vrf in sp2 the border and debug the ip packet in the border
router , it the destination unroutable !!!!!
so the destination not in the routing table but in the vpn4 table and the
router not checking this table !!!!
why is that ……thansk
dayaaBlogs and organic groups at http://www.ccie.net
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
Multicast RPF – Basis
We all know how unicast routing works, when the router receives the packet, the decision on how to forward the packet is made on the destination address, in Multicast the routing decision where to forward the multicast depends on where the packet came from. So the routers much know the origin of the packet, instead of its destination, just the opposite in unicast routing, in multicast, the IP address denotes the know sources (the origin of the multicast traffic), and the destination denotes the group of unknown receivers.
The routers running multicast, use a mechanism called RPF (Reverse Path Forwarding) to prevent forwarding loops and ensure the Shortest path from the source to receivers. Said this we can say that A router forwards multicast traffic only if the received traffic is on the upstream interface to the source, so when a router receives a multicast packet, it is checked against the routing table (unicast), to determine whether the interface the packet arrived provides the shortest path back to the source.
If the interface provides the shortest path to the source the router will forward the packet
If the interface is NOT the shortest path to the source, the router will discard the packet silently
In resume: after the router receives a multicast packet it performs an RPF check. if the RPF check succeeds, the packet is forwarded; otherwise, it is silently discarded,
Now if RPF Succeeds the router will forward this packet out of each interface that is in the Outgoing interface list (OIL), this entries list the interfaces to the current router downstream multicast neighbors
The incoming interface (or RPF Interface) on which the packet was received is never in the OIL, therefore the packet is never forwarded back out this interface
In the above example, each router forwards received multicast packets to each of its neighbor routers. (The arrows that indicate the initial multicast traffic flow from source 10.10.10.10 throughout the network indicate this activity.) Observe that the two routers in the middle of the picture are each receiving multicast packets through the most direct path.
These received packets arrived through the RPF interface, so both routers forward the multicast packets to all neighbors; in this case, each other. This activity results in the two routers receiving packets via the non-RPF interface (that is, an interface that is not on the shortest path to the source) as This result causes the RPF check to fail and the packets to be silently discarded.
Lets do another test, say that the RPF interface is f1/1
now
An RPF check is always done regarding the incoming interface – the RPF interface. The RPF check will succeed if the incoming interface is the shortest path to the source.
The RPF interface is determined either by the underlying unicast routing protocol or the dedicated multicast routing protocol (for example, Distance Vector Multicast Routing Protocol [DVMRP], Multiprotocol BGP Extensions for IP Multicast [MBGP], and so on).
Note that changes in the unicast topology will not necessarily immediately reflect a change in RPF, if the multicast routing protocol relies on underlying unicast routing tables. Such an RPF change depends on how frequently the RPF check is performed on a multicast forwarding entry — every five seconds is the current Cisco default.
QoS Policy Propagation on BGP (QPPB)
QPPB, allows packets to be classified based on access lists, BGP community lists, and BGP autonomous system (AS) paths.
The supported classification policies include IP Precedence setting and the ability to tag the packet with a QoS class identifier internal to the router. After a packet has been classified, you can use other QoS features, such as committed access rate (CAR) and weighted random early detection (WRED).
doneVoice QOS Design Notes:
with LLQ the entrance criteria to a class can be as granular as you like because you define it by an ACL. You are not limited, as with IP RTP priority, to a simple UDP port range. If the port range feature did not get changed
Voice QOS Design Considerations Notes:
General Considerations
- Do not use VoIP on a FR PVC that also carries VoFR
- Prioritize the PVC if it carries only voice traffic
- Don’t mark voice packets as DE
- Set IP Precedence = 5 on the dial peer
- Don’t use WRED for voice queues
- Turn on DTMF-relay for low bit-rate codecs (8k and below)
- Set echo, loss/gain parameters as specified by the network loss plan.
- Measure/calculate network packet delay – the goal is 150 to 200ms one-way.
- If TCP delays affect DTMF-relay performance use Cisco-rtp for DTMF-relay
Queuing Considerations
- LLQ – classify voice in a priority class
- Use ip rtp priority if LLQ is not available
- Set the bandwidth on the priority statement in the LLQ configuration (or in the ip rtp priority statement) to the aggregate number of calls per interface/PVC
- Create ACLs that prioritize both voice media and signaling
Fragmentation Considerations (speeds less than 1.5Mbps
- Fragment to a 10ms delay to optimize size for backbone packet/cell sizes and network delay characteristics
- Set fragments size so that voice packets are not fragmented
- Set the ppp multilink fragment-delay command on leased line interfaces
- Set the frame-relay fragment command in the FR map class
- Fragment all PVCs carrying data on the interface if at least one PVC carries voice
Traffic Shaping Considerations
- Set Be to 0
- Set Bc to 10ms (1/100 of CIR) for mixed voice/data PVCs
- Set mincir greater than or equal to bandwidth needed for voice
- Set FRTS on the interface
- Shape traffic strictly to the CIR on the PVC carrying voice
- Shape both sides of the VC to the slower link speed to prevent egress blocking
CAC Considerations
- Limit voice calls to prevent oversubscription of the bandwidth
Video QoS Design Considerations
- For bidirectional and/or low speed video use priority queuing and allocate 384Kbps for bandwidth
- For one-way video traffic use a CBWFQ mechanism
LLQ Considerations
- Large video MTUs placed in the LLQ’s priority queue with voice traffic will bypass the fragmentation engine and cause delays for the voice traffic.
CAC Considerations
- In a single-zone WAN model limit the number of video terminals
- In a multizone WAN model use Gatekeeper CAC. However, Gatekeeper CAC is only available in a hub-and-spoke network.
Victor Cappuccio
CCIE R/S# 20657
CCSI# 30452
www.anetworkerblog.com
www.linkedin.com/in/vcappuccio
ethertypes on doccd?
Sending a test email…
———- Forwarded message ———-
From: Victor Cappuccio <vcappuccio@gmail.com>
Date: Sun, Jun 14, 2009 at 9:16 PM
Subject: Re: ethertypes on doccd?
To: Wouter Prins <wp@null0.nl>
Cc: Cisco certification <ccielab@groupstudy.com>
Hello Wouter!!
I am not sure if this helps, since the doccd, is not the same, as like in old days 
but here it goes..
IOS ->12.3 Family –>12.3 Mainline —> Command reference —-> Bridging and IBM network Vol 1 of 2 —-> Appedex.
Cisco IOS Bridging and IBM Networking Command Reference, Volume 1 of 2: Bridging, Release 12.3
Appendix: Ethernet Type Code
http://www.cisco.com/en/US/docs/ios/12_3/ibm1/command/reference/ib1_ethc.html
On Sun, Jun 14, 2009 at 8:55 PM, Wouter Prins <wp@null0.nl> wrote:
hi all,
I searched the archives for a link to the doccd that will show me the
different ethertypes for protocols like: pvst(+), mst, ipx and ipv6. I know
ip and ip arp without any references.
Is there a way to issue a debug command to find out the ethertype values of
a particular protocol? I want to avoid learning hex numbers and forget about
them eventually.Tnx.
–
Wouter PrinsBlogs and organic groups at http://www.ccie.net
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
BGP SoO
BGP have loops prevention mechanisms embedded , and we have tools to bypass this aspect of BGP, such as AS-Override or the allowas-in, SOO Extended Community is a loop prevention mechanism needed only for customer networks with multihomed sites. Loops can never occur in stub sites, the SOO Attribute,is used to prevent loops, when EBGP is running between the PE and CE routers, and this attribute is configured using a route-map. Now if the PE-CE routing protocol is not BGP we configure SOO under vrf interface by ip vrf sitemap command, pleease click here to see an example.
router bgp 123 ! address-family ipv4 vrf CCIESP neighbor 6.6.6.6 remote-as 999 neighbor 6.6.6.6 route-map SETSOO in ! route-map SETSOO permit 10 set extcommunity soo 96:96
There are three ways to configure an SoO value for a BGP neighbor:
1.- BGP peer policy template-A peer policy template is created, and an SoO value is configured as part of the peer policy. Under address family IPv4 VRF, a neighbor is identified and is configured to inherit the peer policy that contains the SoO value.
2.- BGP neighbor command-Under address family IPv4 VRF, a neighbor is identified, and an SoO value is configured for the neighbor.
3.- BGP peer group-Under address family IPv4 VRF, a BGP peer group is configured, an SoO value is configured for the peer group, a neighbor is identified, and the neighbor is configured as a member of the peer group. The configuration of SoO values for BGP neighbors is performed on a provider edge (PE) router, which is the VPN entry point. When SoO is enabled, the PE router forwards prefixes to the customer premises equipment (CPE) only when the SoO tag of the prefix does not match the SoO tag configured for the CPE.
Say we want to configure the 1 method as an example
Here, In this example, an SoO tag is set as 1:1 for the customer site that includes routers CPE1 and CPE2 with an autonomous system number of 78. When CPE1 sends prefixes to PE1, PE1 tags the prefixes with 1:1, which is the SoO tag for CPE1 and CPE2. When PE1 sends the tagged prefixes to PE2, PE2 performs a match against the SoO tag from CPE2. Any prefixes with the tag value of 1:1 are not sent to CPE2 because the SoO tag matches the SoO tag of CPE2, and a routing loop is avoided. (that is we see from BGP: .. start import cfg version = 0 BGP(2): 10.1.108.8 soo loop detected for 7.7.7.7/32 – sending unreachable)
Enjoy!!!
Victor.-
BGP.- Filter Tools Summary
Prefix-lists and filter-lists, both in and out, filter routes and discard those that are not permitted.
Weight setting is applicable only on incoming routes because a router never propagates the weight attribute to its neighbors.
Route-maps can be filters that discard routes but can also be used to modify and set various attributes on both incoming and outgoing routes.
Basic BGP .- Part 3 – AS Path Prepending.
When connections to multiple providers are required it is important that Border Gateway Protocol (BGP) select the optimum route for traffic to use. The optimum, or best, route may not be what the network designer intended based on design criteria, administrative policies, or corporate mandate. Fortunately, BGP provides many tools for administrators to influence route selection. One of these tools is autonomous system (AS)-path prepending.
You can manipulate AS paths by prepending AS numbers to existing AS paths. Normally, you perform AS-path prepending on outgoing EBGP updates over the non desired return path
You can configure prepending on a router for all routing updates that you send to a neighbour or only on a subset of them.
When you are manually manipulating AS paths, the only valid AS number that you can prepend is the AS number of the sender. Prepending any other AS number will cause problems.
The longer the AS path that is announced to the EBGP neighbour on the other side of the backup link, the less likely it is that incoming traffic will be received from that neighbour.
done