Cisco

Are you a quitter????I'm not

2012-04-10T01:19:00.001-07:00

It has been two months since I passed my CCIE RS written. Booked my lab in October hoping that 8 months with 3 hours of sleep will be more than enough to be well prepared for the lab exam. I created a spreadsheet to go with the preparation; unfortunately I’ve to drop the preparation for last one due to health issues; still ‘ve not regained the health also. All my preparation plans got ruined. With 7 months in hand for the preparation of the toughest Cisco certification. I was asking myself whether I should drop the lab dates and to postpone for the next year. After thinking for hours I decided that quitting is easier. I’ll move with scheduled date .I believe that if you need something desperately you‘ll find solutions rather than excuses excuse. Let’s see whether my trust and faith lead me to my destination or not. I think its not only about passing or failing; but it’s the courage to face the problems; whether it is CCIE lab exam or its about life. “ll update my status soon about preparation.’ve to change the whole plan for the preparation.

QOS-WFQ: Cisco's Intelligent Queuing Tool for Today's Networks

2011-10-13T10:22:00.000-07:00

For situations in which it is desirable to provide consistent response time to heavy and light network users alike without adding excessive bandwidth, the solution is WFQ. WFQ is one of Cisco's premier queuing techniques. It is a flow-based queuing algorithm that does two things simultaneously: It schedules interactive traffic to the front of the queue to reduce response time, and it fairly shares the remaining bandwidth among high-bandwidth flows.

WFQ ensures that queues do not starve for bandwidth, and that traffic gets predictable service. Low-volume traffic streams---which comprise the majority of traffic---receive preferential service, transmitting their entire offered loads in a timely fashion. High-volume traffic streams share the remaining capacity proportionally between them, as shown in Figure .

WFQ is designed to minimize configuration effort and automatically adapts to changing network traffic conditions. In fact, WFQ does such a good job for most applications that it has been made the default queuing mode on most serial interfaces configured to run at or below E1 speeds (2.048 Mbps).

WFQ is efficient in that it uses whatever bandwidth is available to forward traffic from lower-priority flows if no traffic from higher-priority flows is present. This is different from time-division multiplexing (TDM), which simply carves up the bandwidth and lets it go unused if no traffic is present for a particular traffic type. WFQ works with both of Cisco's primary QoS signaling techniques---IP precedence and Resource Reservation Protocol (RSVP), 'll be described later --to help provide differentiated QoS as well as guaranteed services.

Figure for WFQ, if multiple high-volume conversations are active, their transfer rates and interarrival periods are made much more predictable

The WFQ algorithm also addresses the problem of round-trip delay variability. If multiple high-volume conversations are active, their transfer rates and interarrival periods are made much more predictable. WFQ greatly enhances algorithms such as the SNA Logical Link Control (LLC) and the Transmission Control Protocol (TCP) congestion control and slow-start features. The result is more predictable throughput and response time for each active flow, as shown in Figure show below

This diagram shows an example of interactive traffic delay (128-kbps Frame Relay WAN link).

QOS :Congestion Management Tools

2011-10-13T00:06:00.000-07:00

One way network elements handle an overflow of arriving traffic is to use a queuing algorithm to sort the traffic, and then determine some method of prioritizing it onto an output link. Cisco IOS software includes the following queuing tools:

First-in, first-out (FIFO) queuing
Priority queuing (PQ)
Custom queuing (CQ)
Weighted fair queuing (WFQ)

Each queuing algorithm was designed to solve a specific network traffic problem and has a particular effect on network performance, as described in the following sections.

FIFO: Basic Store-and-Forward Capability

In its simplest form, FIFO queuing involves storing packets when the network is congested and forwarding them in order of arrival when the network is no longer congested. FIFO is the default queuing algorithm in some instances, thus requiring no configuration, but it has several shortcomings. Most importantly, FIFO queuing makes no decision about packet priority; the order of arrival determines bandwidth, promptness, and buffer allocation. Nor does it provide protection against ill-behaved applications (sources). Bursty sources can cause long delays in delivering time-sensitive application traffic, and potentially to network control and signaling messages. FIFO queuing was a necessary first step in controlling network traffic, but today's intelligent networks need more sophisticated algorithms. Cisco IOS software implements queuing algorithms that avoid the shortcomings of FIFO queuing.

PQ: Prioritizing Traffic

PQ ensures that important traffic gets the fastest handling at each point where it is used. It was designed to give strict priority to important traffic. Priority queuing can flexibly prioritize according to network protocol (for example IP, IPX, or AppleTalk), incoming interface, packet size, source/destination address, and so on. In PQ, each packet is placed in one of four queues---high, medium, normal, or low---based on an assigned priority. Packets that are not classified by this priority-list mechanism fall into the normal queue; see Figure 46-3. During transmission, the algorithm gives higher-priority queues absolute preferential treatment over low-priority queues.

Figure below: Priority queuing places data into four levels of queues: high, medium, normal, and low.

PQ is useful for making sure that mission-critical traffic traversing various WAN links gets priority treatment. For example, Cisco uses PQ to ensure that important Oracle-based sales reporting data gets to its destination ahead of other, less-critical traffic. PQ currently uses static configuration and thus does not automatically adapt to changing network requirements.

CQ: Guaranteeing Bandwidth

CQ was designed to allow various applications or organizations to share the network among applications with specific minimum bandwidth or latency requirements. In these environments, bandwidth must be shared proportionally between applications and users. You can use the Cisco CQ feature to provide guaranteed bandwidth at a potential congestion point, ensuring the specified traffic a fixed portion of available bandwidth and leaving the remaining bandwidth to other traffic. Custom queuing handles traffic by assigning a specified amount of queue space to each class of packets and then servicing the queues in a round-robin fashion (see Figure 46-4).

Figure shows a Custom queuing handles traffic by assigning a specified amount of queue space to each class of packets and then servicing up to 17 queues in a round-robin fashion.

As an example, encapsulated Systems Network Architecture (SNA) requires a guaranteed minimum level of service. You could reserve half of available bandwidth for SNA data, and allow the remaining half to be used by other protocols such as IP and Internetwork Packet Exchange (IPX).

The queuing algorithm places the messages in one of 17 queues (queue 0 holds system messages such as keepalives, signaling, and so on), and is emptied with weighted priority. The router services queues 1 through 16 in round-robin order, dequeuing a configured byte count from each queue in each cycle. This feature ensures that no application (or specified group of applications) achieves more than a predetermined proportion of overall capacity when the line is under stress. Like PQ, CQ is statically configured and does not automatically adapt to changing network conditions.

End-to-End QoS Levels

2011-09-20T00:20:00.000-07:00

Service levels refer to the actual end-to-end QoS capabilities, meaning the ability of a network to deliver service needed by specific network traffic from end to end or edge to edge. The services differ in their level of "QoS strictness," which describes how tightly the service can be bound by specific bandwidth, delay, jitter, and loss characteristics.

Three basic levels of end-to-end QoS can be provided across a heterogeneous network, as shown in Figure below

Best-effort service---Also known as lack of QoS, best-effort service is basic connectivity with no guarantees.
Differentiated service (also called soft QoS)---Some traffic is treated better than the rest (faster handling, more bandwidth on average, lower loss rate on average). This is a statistical preference, not a hard and fast guarantee.
Guaranteed service (also called hard QoS)---An absolute reservation of network resources for specific traffic.

Deciding which type of service is appropriate to deploy in the network depends on several factors:

The application or problem the customer is trying to solve. Each of the three types of service is appropriate for certain applications. This does not imply that a customer must migrate to differentiated and then to guaranteed service (although many probably eventually will). A differentiated service---or even best-effort service---may be appropriate depending on the customer application requirements.
The rate at which customers can realistically upgrade their infrastructures. There is a natural upgrade path from the technology needed to provide differentiated services to that needed to provide guaranteed services, which is a superset of that needed for differentiated services.
The cost of implementing and deploying guaranteed service is likely to be more than that for a differentiated service.

Figure belwo shows the three levels of end-to-end QoS are best-effort service, differentiated service, and guaranteed service.

What is QOS?

2011-09-16T03:45:00.000-07:00

QoS refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies. Primary goals of QoS include dedicated bandwidth, controlled jitter and latency (required by some real-time and interactive traffic), and improved loss characteristics. QoS technologies provide the elemental building blocks that will be used for future business applications in campus, WAN, and service provider networks. This chapter outlines the features and benefits of the QoS provided by the Cisco IOS QoS.

The Cisco IOS QoS software enables complex networks to control and predictably service a variety of networked applications and traffic types. Almost any network can take advantage of QoS for optimum efficiency, whether it is a small corporate network, an Internet service provider, or an enterprise network. The Cisco IOS QoS software provides these benefits:

Control over resources---You have control over which resources (bandwidth, equipment, wide-area facilities, and so on) are being used. For example, you can limit the bandwidth consumed over a backbone link by FTP transfers or give priority to an important database access.
More efficient use of network resources---Using Cisco's network analysis management and accounting tools, you will know what your network is being used for and that you are servicing the most important traffic to your business.
Tailored services---The control and visibility provided by QoS enables Internet service providers to offer carefully tailored grades of service differentiation to their customers.
Coexistence of mission-critical applications---Cisco's QoS technologies make certain that your WAN is used efficiently by mission-critical applications that are most important to your business; that bandwidth and minimum delays required by time-sensitive multimedia and voice applications are available; and that other applications using the link get their fair service without interfering with mission-critical traffic.
Foundation for a fully integrated network in the future---Implementing Cisco QoS technologies in your network now is a good first step toward the fully integrated multimedia network needed in the near future.

Basic QoS Architecture

The basic architecture introduces the three fundamental pieces for QoS implementation (see Figure 1):

QoS within a single network element (for example, queuing, scheduling, and traffic shaping tools)
QoS signaling techniques for coordinating QoS from end to end between network elements
QoS policy, management, and accounting functions to control and administer end-to-end traffic across a network

Figure 1: A basic QoS implementation has three main components.

VPDN From Router Over IPSec In MPLS Cloud

2011-09-14T02:30:00.000-07:00

Introduction

Customers are looking for PE-CE security in case of remote access from various locations. The solution which can sophise the requirement is IPSec. With the help of this solution customers traffic send to the PE in the encrypted form and PE will decrypt the packets and forward the various locations vice versa.

Test Setup

The IPSec is tested for VPDN which is being orginated by the customer router. The customer router wil originate the VPDN session towards LNS_test_ipsec, after sucessful authentication, a IP will be given to the CE which will be a part of the vrf and end to end communication will go on.

Basic Connectivity

Routers used 2800 for CE as well as for LNS

Note:- IPSec uses tcp port500 for session establishment. Make sure the ports are open at its end.

Configuration Of LNS PE

aaa new-model
!
!
aaa group server radius default-group
server-private 71.5.101.2 auth-port 1645 acct-port 1646 key 7 06121A2D455E0A160B19170818
ip radius source-interface FastEthernet0/0
deadtime 0
!
aaa authentication ppp default group default-group local
aaa authorization config-commands
aaa authorization network default local group default-group
!
The above commands are used for creating L2 session with radius.

ip cef
!
!
ip vrf TEST
rd 65500:800
route-target export 65500:800
route-target import 65500:800
!
vpdn enable
vpdn multihop
!
vpdn-group 1
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
!
crypto keyring shivlu123 vrf TEST
pre-shared-key address 10.100.101.2 key shivlu123 -> shivlu123 is preshared key and need to be same.
!
crypto isakmp policy 1 ----> Crypto policy created with priority 1
hash md5
authentication pre-share
lifetime 28800
!
!
crypto ipsec transform-set shivlu esp-des esp-md5-hmac
!
crypto map shivlunoc 1 ipsec-isakmp
set peer 10.100.101.2 ---> This is the customer IP address
set transform-set shivlu -----> This is the above shivlu tranfform set which is called here.
set pfs group1 ---------> It could be group 1 or group5
match address 101 --------------> Acl 101 is called
!
interface Loopback100
ip vrf forwarding TEST
ip address 10.100.101.1 255.255.255.252
!
interface Loopback101
ip vrf forwarding TEST
ip address 10.10.10.100 255.255.255.255
!
interface Loopback100001
ip vrf forwarding TEST
ip address 100.250.250.1 255.255.255.248
!
interface FastEthernet0/0
ip address 10.5.230.220 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip vrf forwarding TEST
ip address 10.10.10.1 255.255.255.252
duplex auto
speed auto
!
interface Virtual-Template1
no ip address
no peer default ip address
ppp authentication pap chap callin
ppp multilink
!
ip forward-protocol nd
ip route 10.0.0.0 255.0.0.0 10.5.230.1
no ip http server
no ip http secure-server
!
!
!
ip radius source-interface FastEthernet0/0
access-list 101 permit ip 10.10.10.0 0.0.0.3 10.1.1.0 0.0.0.3
!

Crypto is not called on LNS, it is in RADIUS
--> cd attributes/

[ //localhost/Radius/UserLists/default/test_ipsec@shivlu.blogspot.com/Attributes ]
cisco-avpair = "lcp:interface-config=ip vrf forwarding TEST"
cisco-avpair = "lcp:interface-config=ip unnumbered loopback100"
cisco-avpair = "lcp:interface-config=crypto map shivlunoc"
framed-ip-address = 10.100.101.2 ----> IP will be given after dialing
framed-protocol = ppp
framed-route = 10.1.1.0/30 ---> Customer LAN Route
service-type = framed

Configuratio Of CE End

l2tp-class TestClass
!
!
crypto keyring shivlu123 -> Keyring is used after IP Dialing in VRF
pre-shared-key address 10.100.101.1 key shivlu123
!
crypto isakmp policy 1
hash md5
authentication pre-share
lifetime 28800
!
crypto isakmp peer address 10.100.101.1
set aggressive-mode password cisco
!
!
crypto ipsec transform-set shivlu esp-des esp-md5-hmac
crypto map shivlunoc 1 ipsec-isakmp
set peer 10.100.101.1
set transform-set shivlu
set pfs group1
match address 101
!
!
!
pseudowire-class TestClass
encapsulation l2tpv2
protocol l2tpv2 TestClass
ip local interface FastEthernet0/0
!
!
!
!
!
interface FastEthernet0/0
ip address 10.5.230.101 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.252
duplex auto
speed auto
!
interface Virtual-PPP1 -> Router is intiating ppp session for vpdn after that crypto will be used
ip address negotiated
no cdp enable
ppp chap hostname test_ipsec@shivlu.blogspot.com
ppp chap password 0 cisco
pseudowire 10.5.230.220 100 pw-class TestClass
crypto map shivlunoc
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Virtual-PPP1 --> After VPDN this route will work
ip route 10.0.0.0 255.0.0.0 10.5.230.1 --> This route is added for VPDN dialing
ip http server
no ip http secure-server
!
access-list 101 permit ip 10.1.1.0 0.0.0.3 10.10.10.0 0.0.0.3 -> CE lan to VRF TEST
!

Troubleshooting Commands

1.Check the l2session
LNS_TEST_IPSEC#sh l2tun session
L2TP Session Information Total tunnels 1 sessions 1

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
4 313 10056 test_ipsec@tuli, Vi2 est 00:06:55 3

2. Check the crypto session
LNS_TEST_IPSEC#show crypto session
Crypto session current status

Interface: Virtual-Access2
Session status: DOWN --> Status is down
Peer: 10.100.101.2 port 500
IPSEC FLOW: permit ip 10.10.10.0/255.255.255.252 10.1.1.0/255.255.255.252 -> Acl 101
Active SAs: 0, origin: crypto map

The status is showing down with peer 10.100.101.2. It happens if the traffic is not matching the acl. It means to intiate a session a ping is required with the mentioned acl source and destination.

Ping intiated from
T2800#ping 10.10.10.1 source 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/5/8 ms

Now check the status of crypto on LNS
LNS_TEST_IPSEC#sh crypto session
Crypto session current status

Interface: Virtual-Access2
Session status: UP-ACTIVE -> Showing active with peer 10.100.101.2
Peer: 10.100.101.2 port 500
IKE SA: local 10.100.101.1/500 remote 10.100.101.2/500 Active
IPSEC FLOW: permit ip 10.10.10.0/255.255.255.252 10.1.1.0/255.255.255.252
Active SAs: 2, origin: crypto map

3.Check the Phase 1 with given command
LNS_TEST_IPSEC#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.100.101.1 10.100.101.2 QM_IDLE 1002 ACTIVE
QM_IDLE state means the connection is established.

4. Check the encrypted packets
LNS_TEST_IPSEC#sh crypto engine connections active
Crypto Engine Connections

ID Type Algorithm Encrypt Decrypt IP-Address
1002 IKE MD5+DES 0 0 10.100.101.1
2005 IPsec DES+MD5 0 4 10.100.101.1
2006 IPsec DES+MD5 4 0 10.100.101.1

ID 1002 is for IKE phase 1 and 2005 and 2006 is for IPSec.

Intiate a ping from CE with count 10 and see the packets are encryted
LNS_TEST_IPSEC#sh crypto engine connections active
Crypto Engine Connections

ID Type Algorithm Encrypt Decrypt IP-Address
1002 IKE MD5+DES 0 0 10.100.101.1
2005 IPsec DES+MD5 0 14 10.100.101.1
2006 IPsec DES+MD5 14 0 10.100.101.1

5. IPSec vrf TEST status
LNS_TEST_IPSEC#show crypto ipsec sa vrf TEST
PFS (Y/N): Y, DH group: group1

interface: Virtual-Access2
Crypto map tag: shivlunoc, local addr 10.100.101.1

protected vrf: TEST
local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.252/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.252/0/0)
current_peer 10.100.101.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 14, #pkts encrypt: 14, #pkts digest: 14
#pkts decaps: 14, #pkts decrypt: 14, #pkts verify: 14
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 10.100.101.1, remote crypto endpt.: 10.100.101.2
path mtu 1500, ip mtu 1500, ip mtu idb Virtual-Access2
current outbound spi: 0x2F0548BC(788875452)

inbound esp sas:
spi: 0x1B071345(453448517)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2005, flow_id: NETGX:5, sibling_flags 80000046, crypto map: shivlunoc
sa timing: remaining key lifetime (k/sec): (4441107/3382)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x2F0548BC(788875452)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2006, flow_id: NETGX:6, sibling_flags 80000046, crypto map: shivlunoc
sa timing: remaining key lifetime (k/sec): (4441107/3382)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

L2VPN Over IP/MPLS

2011-09-14T02:26:00.000-07:00

Layer 2 circuits are becoming order of the day. Every service provider desires layer 2 circuits from the other service provider to provision its customers. It can be configured by two methods
a) Point to Point
b) Point To Multipoint
Currently ISR , 6500 and 7200 series supports point to point and 7600 supports point to multipoint. Point to multipoint is also known to VPLS (Virtual Private Lan Services). In this post I will explain about point to point circuit and its provisioning. Services offer on two type of cloud
a) IP Cloud
b) MPLS Cloud
If service provider is using IP cloud, L2 services offer by encapsulation l2tpv3 and if cloud is MPLS enabled then encapsulation mpls can be used. So the difference is lucid. In the given scenario customer is having l2 domain and want to use the l2 services across the service provider cloud. A simple l2 session will be created between Delhi PE and HYD PE over ip cloud on the basics of loopbacks. The provisioning is trouble-free and easy to configure.
Steps for Configuring Layer 2 Services across Service Provider IP Backbone
a) Configure basic IGP.
b) Create PSEUDOWIRE name SHIVLU & use the encapsulation L2TPv3 as source loopback of the router.
c) On Physical interface where the client is coming create a xconnect as destination address of loopback HYD PE & vice versa.
Commands For Creating L2 VPN
Pseudowire SHIVLU
Ip local interface loopback 0
Encapsulation l2tpv3

Interface Specific Command
Interface x/y
Xconnect 400 pw-class SHIVLU
Note:- 400 is the Virtual Circuit ID and it should be the same on the remote end also.

Verify L2 Circuit
After “Show l2 session circuit vcid 400” you can see the est state of l2 session. Now ping end to end laptop.

QoS Policing in Cisco IOS

2011-09-08T04:12:00.000-07:00

The activity called policing or rate limiting in various Cisco IOS releases is actually a traffic contract conformance measurement that can result in marking (changing QoS attributes of individual packets in the traffic flow) or policing (dropping of packets violating the traffic contract).
This document describes various algorithms used to implement rate limiting on non-distributed software-based router platforms running Cisco IOS. Distributed platforms (Cisco 7600, GSR) might use different algorithms depending on software release and the hardware QoS implementations on Catalyst switches differ significantly from the software ones.

Cisco IOS Implementations

Cisco IOS implements policing/marking functionality with two unrelated mechanisms:

The rate-limit command implements per-interface input- and output-rate limiting.
The police command implements the traffic measurement within the scope of the Modular QoS Command Line Interface (MQC).

Rate-limit commands and QoS policy-maps containing the police command can measure inbound or outbound packets on physical or logical interfaces (tunnels, subinterfaces). They introduce no delay (apart from slightly increased CPU load on the router) in the packet forwarding mechanism.

Rate-limit command

The rate-limit interface configuration command can match packets based on IP access lists, IP precedence settings, DSCP settings, QoS groups or source MAC addresses. It can set the IP precedence, DSCP or MPLS QoS bits in the measured packets, or group the packets into QoS groups.
The rate-limit command uses dual token bucket mechanism and drops all packets that exceed the excess burst size.

Police action

The police action specified within a class in a policy-map can use three different measurement mechanisms:

Single token bucket measurement is used when the police command specifies only the conform and exceed actions.
Dual token bucket measurement is used to support conform, exceed and violate actions.
Dual-rate dual token bucket measurement is used when the police command specifies cir and pir rates.

As the traffic measurement takes place within a traffic class defined by a class-map, any criteria supported by the class-map configuration command can be used to define the traffic class.
Each police command can specify three types of actions:

The conform action is executed for packets within the average rate and burst size.
The exceed action for a police command specifying traffic rate is executed for packets within the average rate and excess burst size.
The exceed action for a police command specifying pir rate is executed for packets within the excess rate and excess burst size.
The violate action is executed for packets that exceed excess rate/burst size.

The actions executed by the police command can pass the packet unmodified, drop it or mark it. The following QoS attributes of a packet can be modified:

IP precedence;
IP Differentiated Services Control Point (DSCP);
Discard class (within the DSCP field);
ATM Cell Loss Priority (CLP) – used only for packets transmitted over an ATM interface;
Ethernet 802.1q Class of Services (CoS) marking;
MPLS QoS (experimental) bits – used only for MPLS-encapsulated packets;
Frame Relay Discard Eligibility (DE) bit – used only for packets transmitted over an outbound Frame Relay interface;
QoS group (an extra marker internal to the router).

Measurement Mechanisms

The traffic contracts conformance measurement is usually performed with a token bucket algorithm:

The token bucket size defines the initial burst size that can exceed the average rate.
Tokens (conforming-bytes or conforming-packets) are added to the bucket at a constant rate (the average traffic arrival/departure rate). Tokens exceeding the bucket size are dropped.
Each conforming packet consumes the tokens relative to its size (when measuring packet rate, each packet consumes a single token). Packets exceeding the traffic contract do not consume tokens.

Single Token Bucket Algorithm

The single token bucket algorithm is used for simple traffic contracts that differentiate the measured packets into conforming and non-conforming. The police command using a single token bucket algorithm can specify:

Average traffic bit rate with the rate speed bps parameter or rate percentage percent parameter.

The rate specified with the percent parameter is calculated based on the bandwidth settings of the interface to which the policy-map is applied.

Average packet rate with the rate number pps parameter.
Burst size with the burst size parameter.
Conform and exceed actions with the conform-action and exceed-action keywords.

IOS release 12.4T supports multiple conform-action and exceed-action commands.

The single token bucket algorithm is illustrated in the following figure:

To optimize the token bucket algorithm, the tokens are added to the bucket that the packet arrival time using the following formula: Bucket_new = Min(BurstSize,Bucket_Old + Interpacket-Time * MeasurementRate)

Example

The following router configuration measures the web traffic received through a serial interface and drops all packets exceeding the 512000 bps average rate:

class-map match-any Web
 match protocol http
 match protocol secure-http
 !
policy-map MeasureWeb
 class Web
   police rate 512000 bps
     conform-action transmit
     exceed-action drop
!
interface Serial1/0
 service-policy input MeasureWeb

Dual Token Bucket Algorithm

Slightly more flexible traffic contracts might allow extra (best-effort) packets beyond the average rate/burst size specification. These packets are usually marked differently from the in-contract packets and transported across the network only if it's not congested. In most scenarios, the extra packets are allowed only in the initial burst (long-term traffic rate cannot exceed the average rate) and are measured with an extra token bucket (exceed bucket) as shown in the following diagram:

Dual token bucket contracts are common in ATM environments (where the excess cells are marked with CLP bits) and Frame Relay environments (where the excess frames are marked with the DE bit).
The dual token bucket algorithm is used by the rate-limit command specifying the exceed option and the police command specifying the exceed-action and violate-action. In both cases, the size of the excess burst (but not the average excess rate) can be set.

Example

The following router configuration allows e-mails to be sent at line speed if the size of the transfer does not exceed 100 kilobytes. However, the packets exceeding the 128kbps average rate and the 16 kilobytes initial burst size will be marked with a different DSCP value.

class-map match-any Mail
 match protocol smtp
 !
policy-map LimitEmails
 class Mail
   police rate 128000 burst 16000 peak-burst 100000
     conform-action transmit
     exceed-action set-dscp-transmit af13
     violate-action drop

Dual Rate Policing

In Frame Relay environment, the traffic contracts commonly specify average rate (Committed Information Rate – CIR) as well as constant excess rate (Excess Information Rate – EIR – or Peak Information Rate – PIR) that the customers can use.

The EIR mechanism is different from the excess burst size; the excess burst prolongs the initial packet burst (marking some packets as exceeding the contract) while the EIR allows long-term transmission of excess packets.

The CIR/EIR or CIR/PIR policing requires two independent token buckets as shown in the following diagram. Each bucket independently measures the traffic conformance to the average or peak/excess rate; there is no overflow from the conforming bucket to the excess bucket.

The dual rate policing is configured with the police command specifying cir and pir' rates or rate and peak-rate parameters. In both cases, you can specify the burst size and the peak-burst size (they could be different). You also have to specify conform-action', exceed-action and violate-action; without the violate-action, the single token bucket measurement will be used.

Example

The following service policy can be used on a Frame Relay interface to set the DE bits on excess packets and drop out-of-contract packets:

policy-map FrameRelay
 class class-default
   police cir 128000 pir 256000
     conform-action transmit
     exceed-action set-frde-transmit
     violate-action drop
!
interface serial 1/0.1
 frame-relay interface-dlci 100
 service-policy output FrameRelay

BGP Attribute Types and Flags Continues

2011-09-08T01:25:00.000-07:00

BGP Attributes: Atomic Aggregate Atribute

Atomic aggregate is a Well-known Discretionary attribute; it must be recognized by all BGP implementations and does not have to exist in all BGP updates.
The purpose of the attribute is to alert BGP speakers along the path that some information have been lost due to the route aggregation process and that the aggregate path might not be the best path to the destination.
When some routes are aggregated by an aggregator, the aggregator does attache its Router-ID to the aggregated route into the AGGREGATOR_ID attribute and it sets the ATOMIC_AGGREGATE attribute or not; based on whether the AS_PATH information of the aggregated routes were preserved or not.
AS_PATH information are preserved if you use the AS_SET segment in the AS_PATH attribute. The AS_SET segment is part of the AS_Path attribute and is used to store an unordered list of AS_PATH information of all aggregated routes to prevent possible routing loops. If the AS_SET is not used in the aggregation process the AS_PATH information of the aggregated routes are not preserved and the ATOMIC_AGGREGATE attribute then must be set. However, if the AS_SET is used then PATH information is preserved and the ATOMIC_AGGREGATE attribute is cleared because no information was lost by the aggregation process.
The default behavior on Cisco routers is that the AS_SET is not used, hence the atomic aggregate must be set in the aggregated route. You must use the as-set argument of the aggregate-address command in order for the router to attach the Path information to the aggregated route by generating an AS_SET segment in the AS_PATH attribute.
JUNOS does the opposite by default, Juniper is attaching all the AS Path information to the aggregated path; this means that the ATOMIC_AGGREGATE attribute is not set by default.
The AS-SET segment is used to prevent BGP routing loops as I mentioned before and I believe it should always be used, unless you have a very specific case to omit it (I’ve only done this in a CCIE study LAB scenario).
The Atomic Aggregate attribute will also be set even when using AS_SET if one of the aggregated route is an aggregate itself and has its atomic aggregate attribute already set.
And please have a look at Understanding BGP Route Aggregation at Cisco.com

BGP Attribute Types and Flags Continues

2011-09-08T01:20:00.000-07:00

BGP Attributes: Local Preference Attribute

The local preference attribute is a well-know discretionary attribute. This means local preference must be recognized by all BGP implementations, but will not exist in all BGP update messages; specifically it will not exist in E-BGP update messages.
BGP local preference attribute is one of the most used attributes in BGP real world to influence traffic. Local preference attribute is a four octet field of information that is used to inform internal peers about the autonomous system internal preference for an advertised route.
Local preference will exist in all internal BGP update messages and will never be included in external update messages as I mentioned before, except in the case of BGP confederations.
Local Preference attribute is used to influence traffic in the upload direction; each external route is assigned a preference value based on a configured policy that attaches this preference value to the LOCAL_PREF attribute in the update messages upon sending to internal peers. Local Preference is typically manipulated at the provider edge before sending the route to other internal peers.
When a BGP speaker receives the same route more than once it examines the local preference of the routes and the highest one wins and is considered the best route.
The default value for the LOCAL_PREF attribute is 100 on both Cisco and Juniper routers. This value is changed on IOS routers using a route-map and RPL on IOS-XR while on Juniper routers a policy is used to change the value.
The illustration below makes it more clear, lets check it:

As you can notice in the illustration above , Prefix 192.168.1.0/24 is advertised to AS XYZ from two different upstream providers R1 and R2. The Local Preference attribute value is set using a policy on AS:XYZ edge routers Rx and Ry. Rx sets the value to 200 and Ry sets the value to 150 and both advertise the route to Rz as an iBGP update.
Now, Rz has two routes to the same destination one from Rx and another from Ry but the route through Rx has a higher local preference of 200 and is selected as a best route and moved to the forwarding table.
The very good thing about Local Preference is that it comes first in the best route selection algorithm for BGP providing a clean and easy way to control upload traffic exiting your autonomous system to the internet.

BGP Attribute Types and Flags

2011-09-04T01:29:00.000-07:00

BGP attributes is an interesting subject of study. BGP is a very flexible and extensible protocol and I like that, let’s see how flexible is that protocol when it comes to attributes handling. We all know that BGP has four types of attributes as listed:

Well-known mandatory.
Well-known discretionary.
Optional transitive.
Optional non-transitive.

I am not going to explain them in this post, they are explained everywhere over the internet. However, in short well-known attributes must be recognized by all BGP implementations, some of them are mandatory and must be included in all update messages, others are discretionary and may or may not exist in all BGP updates . Optional attributes do not have to be understood by all BGP implementations. Optional attributes are transited to peers or not, based on the setting of the transitive bit as we will show below.
I will focus on how BGP signals and handles these attributes in update messages. BGP path attributes are sent in BGP update messages; every attribute is a triple of variable length [attribute type, attribute length, attribute value ].
Attribute type is a two octet piece of information that consists of an Attribute Flag octet and an Attribute Type code octet. The Attribute type code speaks for itself and it carries the attribute code number for a specific attribute, for example the origin attribute has a type code number of 1 (see the example below).
And because a picture is worth a thousand words, I will start by a wireshark capture and comment on below.

The Attribute Flag:
The first high order bit (from the left) is the optional bit, setting this bit to 1 means the attribute is optional and to 0 defines a well-known attribute. Origin is a well-known mandatory attribute so this bit is set to zero as you can see.
The second high order bit is the transitive bit. It defines whether the attribute is transitive (value=1) or non-transitive (value=0). Well-known attributes are always transitive and therefore their transitive bit is always set to one.
The third bit is the partial bit, it defines whether the information in the optional transitive attribute is partial (value= 1) or complete (value = 0). Well-known and optional non-transitive are always set to complete. The partial bit is set to 1 in the following cases:

Unrecognized optional transitive attribute that is passed to peers, the sender sets the partial bit.
Optional transitive attribute attached by some router other than the originator or the route.

The fourth bit is the extended length bit and it defines whether the attribute length is one octet or more. The last four bits are not currently used.
The sender orders path attributes in an ascending order (according to attribute type code) within the update message as shown in the packet capture above.

PPP Over Frame-Relay

2011-09-01T07:22:00.000-07:00

Uses a virtual-template interface interface virtual-template 1 which contains your IP address configuration and other L3 stuff like perhaps PPP authentication
- Physical interface links your virtual-template to the interface with frame-relay interface-dlci <dlci> ppp virtual-template 1
- Remember when doing show ip interface brief or other commands, the virtual-template interface will actually show as down. This is normal.
Well those are pretty much my notes for Frame-Relay. This is getting pretty boring and long, so I won’t even go into my notes on the frame configuration right now. One thing I like about writing this stuff out, is that it really actually helps refresh my memory. Hey even if I am boring, I am at least getting something out of it. Consider this as sort of my personal journal, but viewable to the world. It’s really for my benefit as much as anything else.
When I started the configuration video, I got inspired to lab it up for real in my basement. The first part of the video deals with a pretty straight forward Hub and spoke frame network with 1 Hub and 2 spokes. Easy enough…I used a 2520 for my frame switch, a 2511 for an AS, a 2514 for my hub, and a 2501/2502 for my spokes. Unfortunately, I only have 8MB RAM and Flash in most of them, so the best IOS I can still find for download is like 12.1.27 but oh well. It seemed to work pretty well for the purpose. Then Scott added a 4th router for much of the rest of the video and I was screwed because I ran out of DTE/DCE crossover cables. I ordered some more today. I still should really go over actually DOING the back to back exercises as well as the ones involving back to back with frame-relay multilink. Then, when I get add a 3rd spoke going through the other stuff.
Well I hope this is useful for somebody out there

IOS Access List numbering scheme

2011-09-01T07:15:00.000-07:00

The simple CLI parser implemented in early releases of Cisco IOS recognized only numbered access lists. The protocols supported early in the Cisco IOS history were thus using numbered access lists to filter traffic or routing updates.
Most of the access lists were using common address space. Banyan Vines access lists were an exception, they were always configured with the vines access-list configuration command and used their own independent numbering scheme. Rate-limit access-lists (configured with access-list rate-limit number) also use an independent address space.
The first protocol using named access lists was CLNS. Named standard and extended access lists were later added to IP. As numerous IP features still expected an access-list number in the configuration commands even after the named IP access lists were introduced, the address space of the numbered IP access lists was expanded.
The following table documents the IOS access-list numbering conventions:

Start	End	Description
1	99	IP standard access lists
100	199	IP extended access lists
200	299	Protocol type-code access lists (used in bridging filters)
300	399	DECnet standard access lists
400	499	XNS standard access lists
500	599	XNS extended access lists
600	699	AppleTalk cable range access lists
700	799	MAC address access lists (used in bridging filters)
800	899	Novell IPX standard access lists
900	999	Novell IPX extended access lists
1000	1099	Novell IPX SAP access lists
1100	1199	MAC address access lists (extended range)
1200	1299	Novell IPX NLSP access lists
1300	1999	IP standard access lists (extended range)
2000	2699	IP extended access lists (extended range)

Rate limit access lists configured with the access-list rate-limit global configuration command and used in the rate-limit input|output access-group rate-limit number rate interface configuration command use the following numbers (independent from the access-list numbering scheme):

Start	End	Description
1	99	Precedence ACL
100	199	MAC address ACL
200	299	MPLS EXP bits ACL

Banyan Vines access lists configured with the vines access-list number global configuration commands used the following numbering scheme:

Start	End	Description
1	100	Standard ACL
101	200	Extended ACL
201	300	Simple ACL

Feature Comparison of the Nexus 7000 and Catalyst 6500 Series Switches

2011-08-31T22:51:00.000-07:00

After looking at the Nexus 7000 series switches , I concluded they were a lot like the Catalyst 6500 series switches without the service modules.I reviewed the configuration guides for both devices for a comparison of what options each supported today. (These options will change in new OS versions.)
OverviewThe current focus of the Nexus 7000 is to provide high density 10Gb Ethernet switching for LAN traffic primarily in the data center. (Cisco is planning to provide unified I/O supporting SAN traffic on the Nexus 7000 in the future.) My understanding is that service modules or WAN modules in the high performance backplane of the Nexus 7000 would not be very cost effective, so that an external appliance or service layer should be used to provide these features. The NX-OS is based on the Cisco MDS 9000 SAN-OS Software, and focuses on modularity. As needed, you need to enable the features with the feature feature-name configuration command. In the NX-OS 4.1, the following features can be enabled:

feature bgp
feature cts
feature dhcp
feature dot1x
feature eigrp
feature eou
feature glbp
feature hsrp
feature interface-vlan
feature isis
feature lacp
feature msdp
feature netflow
feature ospf
feature ospfv3
feature pbr
feature pim
feature pim6
feature port-security
feature private-vlan
feature rip
feature scheduler
feature ssh
feature tacacs+
feature telnet
feature tunnel
featur udld
feature vpc
feature vrrp
feature vtp

(Some features are available through licensing, others are bundled in the base NX-OS.)
The focus of the Catalyst 6500 is for all purpose enterprise switching and routing, and it supports a multitude of interface types and service modules. The Catalyst 6500 is a work horse of switch. Typically all features in the operating system license are preloaded, and just need to be configured for your specific environment.

Option Summary of the Cisco Nexus 7000 and Catalyst 6500:

Option	Nexus 7000	Catalyst 6500
Operating System	NX-OS 4.0	12.2SXH
switch virtualization support	VDC	VSS
service module support	--	yes
NSF w/ SSO	yes	yes
enhanced Fast Software Upgrade	--	yes
sup engine redundancy	yes	yes
48 port 10/100/1000 Ethernet	yes	yes
four port 10GE linecard	--	yes
eight port 10GE linecard	--	yes
thirty-two port 10GE linecard	yes	--
T1/E1 WAN	--	yes
T3/E3 WAN	--	yes
HSSI	--	yes
T3/E3 ATM	--	yes
OC-3 ATM	--	yes
OC-3 Packet over SONET	--	yes
OC-12	--	yes
OC-48	--	yes
OC-192	--	yes
SONET	--	yes
centralized forwarding	--	yes
distributed forwarding	yes	yes
PoE for GE	--	yes
EtherChannel/Port Channel	yes	yes
Multichassis EtherChannel	yes	yes
VLANs	yes	yes
private VLANs	yes	yes
802.1Q tunneling	yes	yes
Layer 2 Tunneling Protocol	--	yes
RPVST	yes	yes
MST	yes	yes
MPLS	--	yes
AToMPLS	--	yes
FRoMPLS	--	yes
EoMPLS	--	yes
MPLS VPNs	--	yes
iBGP and eBGP	yes	yes
OSPF	yes	yes
EIGRP	yes	yes
ISIS	yes	yes
VRRP	yes	yes
HSRP	yes	yes
GLBP	yes	yes
IP Multicast	yes	yes
IGMPv1/v2/v3	yes	yes
IGMP Snooping	yes	yes
PIMv1/v2	yes	yes
MSDP	yes	yes
SSM	yes	yes
IPv6 routing	yes	yes
IPv6 Multicast routing	yes	yes
Policy Based Routing	yes	yes
QoS - LLQ	--	yes
NBAR	--	yes
VLAN ACLs	yes	yes
CoPP	yes	yes
DHCP Snooping	yes	yes
IP Source Guard	yes	yes
Dynamic ARP Inspection	yes	yes
802.1X Authentication	yes	yes
NetFlow v8	--	yes
NetFlow v9	yes	--
SPAN/RSPAN	yes	yes
Cisco TrustSec	yes	--

Deploying the Nexus 1000V

2011-08-14T22:36:00.000-07:00

The Cisco Nexus 1000V is, of course, a Layer 2 distributed virtual switch for VMware vSphere built on Cisco NX-OS (the same operating system that drives the physical Nexus switches). It’s compatible with all switching platforms, meaning that it doesn’t require physical Nexus switches upstream in order to work. The Nexus 1000V brings policy-based VM connectivity, network and security property mobility, and a non-disruptive operational model.
The Nexus 1000V has two components: the Virtual Supervisor Module (VSM). Interestingly enough, the slide shows that the VSM can be a virtual or physical instance of NX-OS; there has been no formal announcement of which I know that has discussed using a physical instance of NX-OS as the VSM for the Nexus 1000V. The second component is the Virtual Ethernet Module (VEM), which is a per-host switching module that resides on each ESX/ESXi host. A VSM can support up to 64 VEMs in a distributed logical switch model, meaning that all VEMs are centrally managed by the VSM. Each VEM appears as a remote line card to the VSM.
The VEM is deployed using vCenter Update Manager (VUM) and supports both ESX and ESXi. The Nexus 1000V supports both 1Gbps and 10Gbps Ethernet uplinks and works with all types of servers (everything on the HCL) and upstream switches.
The Nexus 1000V supports a feature called virtual port channel host mode (vPC-HM). This feature allows the Nexus 1000V to use two uplinks (NICs in the server) connected to two different physical switches and treat them as a single logical uplink. This does not require any upstream switch support. Multiple instances of vPC-HM can be used; for example, you could use four Gigabit Ethernet uplinks, two to each physical switches, could be used to create two different vPC-HM uplinks for redundancy and separation of traffic.
For upstream switches that support VSS or VBS, you can configure the Nexus 1000V to use all uplinks as a single logical uplink. This requires upstream switch support but provides more bandwidth across all upstream switches. Of course, users can also create multiple port channels to upstream switches for traffic separation. There are lots of flexiblity in how the Nexus 1000V can be connected to the existing network infrastructure.
These network designs can be extrapolated to six NICs (uplinks), eight NICs, and more.
One interesting statement from the presenter was that Layer 8 (the Human layer) can create more problems than Layers 1 through 7.
Next, the presenter went through the use and configuration of the Cisco Nexus 1000V in DMZ environments. Key features for this use case include private VLANs (private VLANs can span both physical and virtual systems). Network professionals can also use access-conrol lists (ACLs) and remote port mirroring (ERSPAN) improve visibility and control over the virtual networking environment.
At this point, I left the session because it was clear that this session was more about educating users on the features of the Nexus 1000V and not about best practices on how to deploy the Nexus 1000V.

Red Pill or Blue Pill

2011-08-12T21:56:00.000-07:00

Life is a matter of choice.The most difficult thing in life is to make a right choice.We are always scared to make the choice.Life may knocks down us,but it our choice to stand up or not.I decided to stand up and fight for my existence.I started my journey towards CCIE.The choice you take today 'll reflect your tomorrow.So are you ready to make the choice????

Virtualization Still Calls Data-Center Tune

2011-02-13T23:23:00.001-08:00

As the latest VMworld begins its transformation from current event to memory, now probably is as good a time as any to reflect on what it all means, if anything, for the future of data centers, the IT industry, and various big-name vendors.
There has been a lot of talk about public, private, and hybrid clouds at VMworld, but I think that’s something of a side issue. Yes, certain enterprises and organizations will partake of cloud services, and, yes, many enterprises will adopt a philosophy of IT as service within their data centers. They’ll make data-center management and automation decisions accordingly.
Even so, at a practical level, it is virtualization that continues to drive meaningful change. The robust growth of virtualization has introduced problems (optimists would call them opportunities), too. How do you automate it, how do you manage it, how do you control it so that it remains a business asset rather than a potential liability?
Reciprocal Choking
At a fundamental level, that’s the big problem that data centers, whether within enterprises or service providers, must solve. The ultimate solution might involve data- center convergence — the integration and logical unification of servers, storage, networking, and orchestration — but it’s not clear whether that is the only option, or whether the price of vendor lock-in is worth the presumed benefit. Most enterprise customers, for the time being, will resist the urge to have one throat to choke, if only because they fear the choking might be reciprocal.
Indeed, as the vendor community has reacted to the popular appeal of data-center virtualization, the spectacle has been fascinating to watch. Who will gain control?
It’s not a simple question to answer, because the vendors themselves won’t have the final say; nor will the industry’s intelligentsia and punditry, formidable as they may be. No, the final arbiters are those who own, run, and manage the data centers that are being increasingly virtualized. Will network managers, or at least those with a strong networking sensibility, reign supreme? Will the leadership emerge from the server, application, or storage side of the house? What sorts of relationships will these customers have with the vendor community, and which companies will serve as trusted counsel?
Ownership of Key Customer Relationships
As virtualization, by necessity, breaks down walls and silos, entirely new customer relationships will develop and new conversations will occur. Which vendors will be best positioned to cultivate or further develop those relationships and lead those conversations?
Meanwhile, vendors are placing their bets on technologies, and on corporate structures and strategic priorities. HP is an interesting case. Its Enterprise Servers Storage and Networks (ESSN) seems increasingly titled toward storage and servers, with networking — though not an insignificant consideration — relegated increasingly to a commoditized, supporting role. Just look at the executive management at the top of ESSN, both at HP headquarters and worldwide. You’ll notice an increasingly pronounced storage orientation, from Dave Donatelli on down.
Cisco, meanwhile, remains a networking company. It will try to imbue as much intelligence (and account control) as possible into the network infrastructure, even though it might be packaged under the Unified Computing Systems (UCS) moniker. That might not be a bad bet, but Cisco really doesn’t have a choice. It doesn’t own storage, is a relative neophyte in servers, and doesn’t have Oracle’s database or application pedigree.
Dell’s Move
IBM and Dell will be interesting to watch. Dell clearly places a lot of emphasis on owning its own storage technology. It has its own storage offerings right up through the midrange of the market, and it tried hard to buy 3PAR before being denied by a determined HP, which had its own reasons for winning that duel.
Questions remain over the importance Dell attaches to networking. We should learn soon enough whether Dell will continue to partner, with Juniper and Brocade, or whether it will buy its way into the market. To the extent that Dell continues to maintain its networking partnerships, the company effectively will be saying that it deems networking a secondary priority in its data-center strategy. IBM already seems to have made that determination, though there’s always a possibility it will revisit its earlier decision.
This puts Juniper in an interesting position. It needs to continue to push toward its Project Stratus intelligent flat network, thereby enhancing its value to customers and its importance to Dell and IBM as a partner. Brocade faces a similar challenge in storage networking, though it still seems to have a lot of work ahead of it in repositioning the Ethernet-switching portfolio it obtained through its acquisition of Foundry Networks.
Microsoft Pays for Inattentiveness
I have not mentioned Microsoft. VMware threw down a gauntlet of sorts earlier this week when it suggested that the importance of Windows as an operating system had been undercut severely by the rise of virtualization. For the most part, I agree with that assessment. Microsoft has some big challenges ahead of it, and it has been attempting to distract us from its shortcomings by talking a lot about its cloud vision. But a vision, no matter how compelling, is thin gruel if it is not supported by follow through and execution. In virtualization, Microsoft was caught flat-footed, its gaze averted by commotion outside the data center and the enterprise, and it is paying a steep price for that inattentiveness now.
Even though marketing hype has pivoted and tilted toward the cloud, virtualization continues to recast the data center.

Companies slow to adopt NAC technology

2011-02-13T23:22:00.000-08:00

Companies are showing little interest in expanding their interest in network access control even though many are interested in such technology.
According to a new report from Forrester, only 10 percent of organisations plan to implement the technology in the coming year. The research company said that security professionals were struggling to deliver business cases to justify the use of the technology
Those companies that are going down the NAC path are overwhelmingly opting for client-side technology. According to Forrester 27 percent of respondents report adoption of a client-side NAC technology. Report author, Usman Sindhu, claimed there were several reasons for this. "Client-side NAC technology is software-based, so IT and security professionals can more easily integrate and manageit," he wrote, adding that during the past 18 months, many security vendors have bundled NAC technology into their client security suite products, thus accelerating its adoption. We're seeing vendors like McAfee and Symantec using NAC as a feature in a suite or a bundled client security offering,"
Conversely, server-side NAC is less popular, only 17 percent of the respondents in the Forrester survey are interested in going down this route. These products include NAC technology integrated into routing and switching infrastructure or operating as separate NAC appliances. Security professionals struggle to make a business case for these devices because of the capital cost involved.

Sindhu makes four predictions for 2011. Firstly greater interest in NAC integrated into broader security offerings will flourish. He said that this had gone beyond security vendors themselves." For instance, Cisco and Juniper are keen on making NAC one feature in the infrastructure security stack. This trend is here to stay and will push other players to abandon the standalone NAC approach"
The second of Sindhu's predictions is that network access control will shift to the layered access control model. "Access control will encompass not only the network but also applications and mobile devices. The term "NAC" will not go away, but it will refer to network, application, and device access control. NAC solution vendors will work with partners to provide a layered access control where the focus is the user, not the device."
Sindhu's third prediction is that hybrid deployment modes will continue to be popular. "Security organisations don't have a clear preference for hardware-based versus software-based NAC deployments," he wrote, preferring to use a combination of deployments. He said that this trend would continue into 2011.
Finally, Sindhu said that in 2011, compliance-driven features will dominate the market. He said that companies would expand their compliance needs by taking on board employee-owned devices such as smartphones and tablets.

A new look at SAN Fabric Switching: Performance, Flexibility and VALUE

2011-02-13T22:25:00.000-08:00

In the past, SAN Fabric switches filled a particular niche, offering stripped-down functionality to serve basic connectivity needs, while only director-class products offered greater performance and flexibility. Pure connectivity solutions, without scalability and performance options, are not acceptable in those environments any more.

With the introduction of Cisco MDS 9148 Fabric Switch, we’ve raised the bar for SAN Fabric solutions by providing a feature-rich, high performance (8-Gbps line rate) switch which scales non-disruptively in eight-port increments from 16 to 48 ports, all at an entry-level price point.

The MDS 9148 offers similar value to director-class switches with enterprise features including VSANs, security, non-disruptive firmware updates, and NPV, providing mid-market customers with the versatility and capability needed to grow their businesses.

Most importantly, not only does the “pay-as-you-grow” model reduce the initial investment, all advanced features continue to be delivered as part of Cisco’s standard SAN package, not as upgrades or separate licenses which add significant incremental costs to competitive solutions.

To clarify, this Cisco solution is not only for mid-market customers. Due to its redundancy (including dual power and dual fans), scalability and line rate performance, the MDS 9148 switch is an ideal candidate for deployment in top-of-rack architectures and departmental SANs at larger organizations as well. The MDS 9148 is powered by NX-OS, a common OS that spans the MDS, Nexus and UCS 6100 families of products. Having a common OS among both storage and Ethernet switches decreases IT’s learning curve and enables greater staff flexibility in large IT organizations.

ESG tested our switch and validates our claims; the ESG Lab found that “the MDS 9148 is a rock-solid, feature-rich, 8-Gbps multilayer fabric switch that cost effectively delivers the benefits of SAN-attached connectivity to small- and medium-size businesses and enterprises looking for affordably powerful edge connectivity.” You can read their report here.
One of our partners in Europe, MTI, tested the MDS 9148 and found that that the VM optimization features in the MDS 9148 makes this an ideal platform of choice for Virtual Machine environments and is very easy to setup and manage. You can read the MTI test report here.

Bit Torrent Killed My Router

2011-02-13T22:17:00.000-08:00

I'm a long time Vonage customer and I have a very old Vonage Motorola VT1005 VOIP Router that they gave me when I signed up way back in 2003. It turns out that this box can't handle all the action that Bit Torrent sends its way; something about a limited size of the NAT table not working with the large number of connections opened by Bit Torrent. Typically it needs to be reset at least once a day when any sort of Bit Torrent activity is going on.

The solution is to keep the poor VT1005 out of the way of all that traffic. Instead of using it as your main router, stick it behind something more up to the task, like an Apple Airport Extreme. Of course the VOIP functionality works best if there is no firewall between it and the network at large. The solution to this is to put the VT1005 in the DMZ of your main router. To do this you first need to make sure the VT1005 has a static IP address. You can set this on using the web interface of the VT1005. After that, go to the admin interface for your main router and set this new IP address as the DMZ IP address. On the Airport Extreme this setting is called Enable Default Host, as you can see in the image above.

There are a few other issues to be aware of when dealing with the VT1005. It has an advanced setting so you can disable NAT and put it in bridge mode. This seems like a good idea since it ought to avoid the NAT table explosion, but that solution seems to have the same daily reset issue. Also, it's a bit tricky to get back to the web interface of the VT1005 if you've put it into bridge mode. There is no way to get to the device after that! The trick is to directly connect your computer to the VT1005's PC port and set the IP address of your computer statically to 192.168.102.2 with the gateway set to 192.168.102.1. Then point your browser to http://192.168.102.1/ and you'll be able to change the NAT settings again. Finally, make sure you have the VT1005 set to use the factory MAC address. I was trying to fake out my ISP and set the MAC address to the same number as my Airport Extreme. This will work if you ISP gives you more than one IP address and you're in bridge mode (NAT disabled). But it won't work if the Vonage box is setup in your DMZ. Your router and the computer in the DMZ can't have the same MAC address or things just won't work.

Configuring the Cisco WVC80N on Sensr

2011-02-13T22:14:00.000-08:00

I recently found the Cisco WVC80N for sale at Best Buy. I was visiting my relatives in the Midwest and hoping to buy a camera that I could configure for them with sensr.net. To use network cameras with Sensr, you need one that supports FTP. I was disappointed to find that FTP was not listed on the side of the box. Since this was the only network camera they had, and the store was closing in 10 minutes, I did a quick search from my iPhone and found this FAQ, indicating that indeed the camera will support FTP.

I went ahead and bought the camera. It was a bit pricey at $150 but I figured that if it didn't work, I could return it the next day. Best Buy has a pretty decent return policy. In this case that worked in their favor, as I'm sure it does many times.

As with many of these network cameras, the setup software only works on Windows. If you have a Mac or Linux, you'll have to forgo the software install, which in my opinion is probably a good thing. There is no reason you should need to install software on your PC to setup or use a network camera.

So a couple of things I learned. First, by default, the camera will grab an IP address over the ethernet using DHCP. This is pretty standard. The trick with these cameras is to find the IP address that your router gives out. The above mentioned FAQ also says the default IP is 192.168.1.100. This is NOT the case if your network has DHCP, which is probably the case. I found the IP address by looking at the clients table on the home network's router.

The second thing I learned was that the camera doesn't support timed FTP. This means you can't simply have the camera FTP images every second, which is the way I like to setup cameras on sensr.net. As a work around, I turned on Motion Detection for the camera and told it to FTP the images to sensr.net. I then set the motion detection level as sensitive as possible. Unfortunately to set the overall sensitivity, you need to use Internet Explorer, since that configuration is set using an Active X control. Yuck!

The advantage of having Sensr, rather than the camera, do the motion detection, is that the live views are much more interesting. If your camera only sends images to Sensr when there is motion, the Live Preview links from the sensr.net site won't be very interesting.

Sensr does support camera based motion detection. Basically this means motion detection on the sensr.net site is turned off, and we'll assume every image coming from your camera should be saved. (We still have limits on the number of images we'll save, currently 600 per hour.)

Overall I would not recommend the WVC80N. My main gripes are:

Lack of timed FTP uploads
Active X is required for the web configuration
Too expensive

You would be better off buying the Dlink DCS-920 which works well with Sensr and is considerably cheaper.

Learn to configure Cisco IOS NAT on a stick

2011-02-13T22:11:00.000-08:00

“NAT on a stick” is not a common Cisco router configuration, but it is a tool that you will want to understand in case you ever have a situation that calls for it.

A well known NAT configuration is called “NAT on a stick.” Besides having a funny name, NAT on a stick can be very useful to network administrators. In this article, learn what NAT on a stick is and how it can help you.

What is Network Address Translation?

Network Address Translation (NAT) is used to translate IP addresses from one network into IP addresses for another network. NAT is performed by a router and is commonly used to translate private IP addresses used in homes and businesses into the public IP addresses that are used on the Internet.

When configuring NAT, there are a number of terms and concepts you need to know. For example: the difference between inside local, inside global, outside local, outside global, NAT vs. PAT, and “NAT overload.”

I don’t recommend that you configure NAT on a stick until you have a good understanding of NAT. I recommend that you try one of the easier NAT configurations prior to NAT on a stick.

What is NAT on a stick?

First, the “stick” is just a single router interface. As NAT is typically performed between two router interfaces, NAT on a stick is used to describe a NAT configuration where a single router interface is used and NAT is performed. Thus, we are really talking about NAT on a single-router interface (but that’s not as catchy, is it?).

For NAT to work, a packet has to be sent from an inside NAT interface to an outside NAT interface. This is still true with NAT on a stick, but we are able to get around having only a single interface because we use a virtual interface to accomplish the same task. You use a policy-based route (PBR) to route and NAT the traffic between the virtual interface, which is a Cisco IOS loopback interface, and the physical interface.

Prior to configuring NAT on a stick, you should make sure that your Cisco IOS supports this feature.

How can NAT on a stick help you?

NAT on a stick is not what I would consider a common configuration. However, I have seen it listed on Cisco certification exam objectives; I have heard Cisco instructors talk about it; and I have had readers ask me questions about it. So, even though you won’t find NAT on a stick in use on most enterprise networks, I think that it is important that you know what it is, how it can help you, and that it is yet another tool available to you, should you need it.

While there are a number of options for using NAT on a stick, here is a scenario in which I’ve seen it in use. (I have selected this scenario because it is based on the official Cisco documentation on this topic where you can go to find more information.)

You have a LAN with a number of computers, a single Cisco router with one Ethernet interface, and a cable DSL modem. Your ISP has given you a single IP address plus a block of two other IP addresses on a different network. Usually, you would get around this by using NAT (actually PAT or NAT overload) with a home/SMB router such as Linksys, Netgear, D-Link, or Belkin. But let’s say that you want to use a Cisco router only, and unfortunately, all you have is a 2501 (single Ethernet and Serial interface). The DSL modem is just a bridge (not a router) and the Cisco router cannot be connected directly to the cable modem because the router only has one LAN interface. You put a small hub in between the DSL modem and the 2501 Cisco router.

While this might sound like a wild scenario to some, and we all agree that you just need to buy more hardware — I don’t want to leave out any possible option that you could consider for using the Cisco IOS to solve a problem. Should this configuration be used on the Internet in production? No. Is it valuable to know how to configure NAT on a stick? Absolutely!

How do you configure NAT on a stick?

The sample configuration below for NAT on a stick is based on the following details: The local LAN is the 192.168.1.0 network. You are given one useable IP address on this network from the ISP, plus a block of two IP addresses on the 192.168.2.0 network. This network has access to the DSL modem. The 10.0.0.0 network is the LAN where you will have as many devices as you want and the devices on that LAN will rely on NAT on a stick.

Remember — the Cisco IOS loopback interface is the virtual interface that helps us get around the “one interface only” issue. Here is what you need to do:

Configure Interfaces with NAT statements and IP policy routing

interface Loopback0

 ip address 10.0.1.1 255.255.255.252

 ip nat outside

interface Ethernet0

 ip address 192.168.1.2 255.255.255.0 secondary

 ip address 10.0.0.2 255.255.255.0

 ip nat inside

 ip policy route-map nat-loop

Configure your NAT pools

ip nat pool external 192.168.2.2 192.168.2.3 prefix-length 29

ip nat inside source list 10 pool external overload

Ensure that you have IP Routes

ip route 0.0.0.0 0.0.0.0 192.168.1.1

ip route 192.168.2.0 255.255.255.0 Ethernet0

Create ACLs for NAT and the Policy Routing

access-list 10 permit 10.0.0.0 0.0.0.255

access-list 102 permit ip any 192.168.2.0 0.0.0.255

access-list 102 permit ip 10.0.0.0 0.0.0.255 any

Create the Route Map that is applied to the Ethernet interface

route-map Nat-loop permit 10

 match ip address 102

 set interface loopback0

With this configuration, the PC clients, assigned with 10.0.0.x network IP addresses will be NATed when their traffic arrives on the Ethernet0 interface. That NATing will use the 192.168.2.x pool.

You should note that you will have to configure the router’s primary Ethernet IP as the default gateway for all PCs in the NAT network. Also, you will also have to do ONE of the following:

1. Have the ISP or any other router on the other side of the NAT network create a static route for your 192.168.2.0/29, pointing to your router’s 192.168.1.2 IP address

2. Have your router advertise that network (in #1) via a dynamic routing protocol like RIP, OSPF, or EIGRP

This configuration is based on the example provided in Cisco’s official Network Address Translation on a Stick documentation. Please review it if you have questions on this example as it has a diagram and debug steps.

In Conclusion

NAT on a Stick is one of the many tools that a network admin may need to employ in certain situations. If nothing else, it is a configuration that you should recognize by name if you are asked about it on certification exams or by colleagues. For some admins, it is an irreplaceable tool.