OSPF Fast Hello Packets - Hmm whats that ?

I know that many or should say most of people in Networking world knows about basics of OSPF hello packets and what they are meant for. I guess I came to know about ospf hello packets first during my ccna studies . But later during my ccnp studies I learned some more details of it like what information is carried within ospf hello packet and all. So there is nothing new in that.

 

But an year back when I started preparing for my CCIE certification , I came to know about interesting new IOS feature called OSPF Fast Hello Packets.  This feature was basically introduced to enhance fast convergence capabilities of ospf protocol. So lets discuss about it:

OSPF hello packets are packets that an OSPF process sends to its OSPF neighbors to maintain

connectivity with those neighbors. The hello packets are sent at a configurable interval (in seconds). The defaults are 10 seconds for an Ethernet link and 30 seconds for a non broadcast link. Hello packets include a list of all neighbors for which a hello packet has been received within the dead interval. The dead interval is also a configurable interval (in seconds), and defaults to four times the value of the hello interval. The value of all hello intervals must be the same within a network. Likewise, the value of all dead intervals must be the same within a network.

These two intervals work together to maintain connectivity by indicating that the link is operational. If a router does not receive a hello packet from a neighbor within the dead interval, it will declare that neighbor to be down.

OSPF fast hello packets refer to hello packets being sent at intervals of less than 1 second.

OSPF fast hello packets are achieved by using the ip ospf dead-interval command. The dead interval is set to 1 second, and the hello-multiplier value is set to the number of hello packets you want sent during that 1 second, thus providing sub second or “fast” hello packets.

When fast hello packets are configured on the interface, the hello interval advertised in the hello packets that are sent out this interface is set to 0. The hello interval in the hello packets received over this interface is ignored.

The dead interval must be consistent on a segment, whether it is set to 1 second (for fast hello packets) or set to any other value. The hello multiplier need not be the same for the entire segment as long as at least one hello packet is sent within the dead interval.

The benefit of the OSPF Fast Hello Packets feature is that your OSPF network will experience faster convergence time than it would without fast hello packets. This feature allows you to detect lost neighbors within 1 second. It is especially useful in LAN segments, where neighbor loss might not be detected by the Open System Interconnection (OSI) physical layer and data-link layer.

Example:

Router(config-if)# ip ospf dead-interval minimal hello-multiplier 5

Because the multiplier is set to 5, five hello packets will be sent

every second. That means one hello packet in every 200 milliseconds

Hmmm...lets verify this:

Router# show ip ospf interface ethernet 1/3

Ethernet1/3 is up, line protocol is up

Internet Address 172.16.1.2/24, Area 0

Process ID 1, Router ID 172.17.0.2, Network Type BROADCAST, Cost:1

Transmit Delay is 1 sec, State DR, Priority 1

Designated Router (ID) 172.17.0.2, Interface address 172.16.1.2

Backup Designated router (ID) 172.16.0.1, Interface address 172.16.1.1

Timer intervals configured, Hello 200 msec, Dead 1, Wait 1, Retransmit 5

Best Regards,

Deepak Arora

Some More Funny RFCs - gr8 collection :)

http://en.wikipedia.org/wiki/April_Fools'_Day_RFC

Also directly get RFC PDF - http://tools.ietf.org/pdf/usage.shtml

Local Proxy ARP - hmmm it's not ordinary ip proxy ARP

The local proxy ARP feature allows the Multilayer Switching Feature Card (MSFC) to respond to ARP requests for IP addresses within a subnet where normally no routing is required. With the local proxy ARP feature enabled, the MSFC responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet. Use this feature only on subnets where hosts are intentionally prevented from communicating directly to the Catalyst 6500 series switch on which they are connected.
Before the local proxy ARP feature can be used, the IP proxy ARP feature must be enabled. The IP proxy ARP feature is enabled by default.
Internet Control Message Protocol (ICMP) redirects are disabled on interfaces where the local proxy ARP feature is enabled.
Examples
The following example shows how to enable the local proxy ARP feature:
Router(config-if)# ip local-proxy-arp

Best Regards,
Deepak Arora

CCIE Certification - Few Words

The CCIE is Cisco's expert-level certification. Created in 1993, the CCIE program was the first certification program developed by Cisco. To achieve CCIE status you first must pass a comprehensive written qualification exam. A passing score on the qualification exam entitles you to register for the true challenge: an intensive, hands-on lab exam conducted at one of several Cisco locations around the world. The lab exam lasts a full day and will test your ability to quickly configure and troubleshoot a complex internetwork to exacting specifications using a variety of Cisco hardware components.

Simple but Interesting NAT question - Good to know for interview :-)

Around an year back I have been asked a question in interview - hey If a packet is coming to router for both NAT and Routing purpose than what will router do first - Routing & then Natting or Natting then Routing ?

Hmmm...interesting one...Isn't it

I said Routing first and then Natting.
Let me explain why...See if a packet is coming to router on which it has to perform both routing and natting functions than in that case routing function will take precedence. Reason is if a packet is not supposed to be forwarded after routing check than why would router perform Nat function first and later will drop packet because no routing is found for destination subnets. I mean if router will perform Natting first than we are just increasing it's over head. Simple if we are not going to route a packet than we need not to perform Natting on it first.

Best Regards,
Deepak Arora

How Router makes a routing decision :-)

"CLICK ON IMAGE TO ENLARGE"

So...today we gonna discuss in brief about how router makes a routing decision for the same destination subnets while running two different routing protocols togather. This article is very much dedicated to CCNA, CCNP people. The reason is ....hmmm....they never been taught about the right way. Reason could be like we need not to get into that much depth about advance routing decisions at initial and professional level. Anyways....I learned this when I started preparing for my CCIE around an year back.
So next time if someone ask ...hey if I have two routers running EIGRP and OSPF both, which routing protocol will indeed used to exchange routes and to send data ? Typical answer would be - EIGRP...cause it's AD is 90 where as OSPF AD is 110...so EIGRP will be the winner :)
Nooooo...but may be Yes too :) , just ask them for configuration first
Let me explain step by step approach of router while making routing decisions in such situation:
1.) Check for the longest prefix match....just look into the Diagram...in short EIGRP 1 process is enabled on R1's interfaces f0/0 & s0/0 & On R2 the EIGRP 1 process is enabled on interfaces f0/0 & s0/0 too. Also I have configured OSPF 1 routing process on R1's f0/0 & so/1, R2's f0/0 & s0/1, R3's s0/0 & s0/1.
Now most people will say that the traffic originated from R1's ethernet subnet will exit through R1's interface s0/0 because it's running EIGRP and as we know AD of EIGRP is 90 so it will take preference over OSPF AD 110. But in actual it's moreover dependent on your routing protocol configuration. So lets hop on to configuration :-)

R1(config)#do sh run be router
router eigrp 1

network 3.3.3.1 0.0.0.0

network 10.0.0.1 0.0.0.0

auto-summary

!

router ospf 1
log-adjacency-changes

network 1.1.1.1 0.0.0.0 area 0

network 10.0.0.1 0.0.0.0 area 0

!

R2#sh run be router

router eigrp 1

network 3.3.3.2 0.0.0.0

network 20.0.0.1 0.0.0.0

auto-summary

!

router ospf 1

log-adjacency-changes

network 2.2.2.2 0.0.0.0 area 0

network 20.0.0.1 0.0.0.0 area 0

!

R3#sh run be router

router ospf 1

log-adjacency-changes

network 1.1.1.2 0.0.0.0 area 0

network 2.2.2.1 0.0.0.0 area 0

!

Now let's take a look at the routing table
R1(config)#do sh ip route

Gateway of last resort is not set
1.0.0.0/30 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Serial0/1

2.0.0.0/30 is subnetted, 1 subnets

O 2.2.2.0 [110/128] via 1.1.1.2, 00:01:21, Serial0/1

3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 3.3.3.0/30 is directly connected, Serial0/0

D 3.0.0.0/8 is a summary, 00:04:19, Null0

20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

O 20.0.0.0/24 [110/138] via 1.1.1.2, 00:01:21, Serial0/1

D 20.0.0.0/8 [90/2195456] via 3.3.3.2, 00:04:19, Serial0/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 10.0.0.0/24 is directly connected, FastEthernet0/0

D 10.0.0.0/8 is a summary, 00:04:19, Null0

Oops...We are learning R2's 20.0.0.x network through both routing protocols :-(
So whats next....

But if we take a closer look we can see the difference. Through EIGRP we are learning 20.0.0.0 network with /8 prefix length. While on the other hand through OSPF we are learning the same destination network with /24 prefix length. So if you remember EIGRP by default summarize advertised networks to their default class mask while there is no default summarization behavior in OSPF so it advertises the network with proper mask.
But we still have both entries from both protocols in routing table so which one will take precedence ?
Answer: The routing protocol which is providing more accurate route to routing table then other one..which in our case is OSPF with /24 prefix length :-)
So lets test it out....I am going to run a ping test after enabling Debug ip packet command to see which interface icmp packets will choose to reach destination
here we go...

R1(config)#do ping 20.0.0.1 source 10.0.0.1

*Mar 1 00:07:19.647: IP: tableid=0, s=10.0.0.1 (local), d=20.0.0.1 (Serial0/1), routed via FIB*Mar 1 00:07:19.647: IP: s=10.0.0.1 (local), d=20.0.0.1 (Serial0/1), len 100, sending

*Mar 1 00:07:20.467: IP: tableid=0, s=20.0.0.1 (Serial0/0), d=10.0.0.1 (FastEthernet0/0), routed via RIB

*Mar 1 00:07:20.467: IP: s=20.0.0.1 (Serial0/0), d=10.0.0.1, len 100, rcvd 4

*Mar 1 00:07:20.471: IP: tableid=0, s=10.0.0.1 (local), d=20.0.0.1 (Serial0/1), routed via FIB

*Mar 1 00:07:20.471: IP: s=10.0.0.1 (local), d=20.0.0.1 (Serial0/1), len 100, sending

*Mar 1 00:07:20.611: IP: tableid=0, s=20.0.0.1 (Serial0/0), d=10.0.0.1 (FastEthernet0/0), routed via RIB

*Mar 1 00:07:20.611: IP: s=20.0.0.1 (Serial0/0), d=10.0.0.1, len 100, rcvd 4

*Mar 1 00:07:20.615: IP: tableid=0, s=10.0.0.1 (local), d=20.0.0.1 (Serial0/1), routed via FIB!!!

So now you can see that icmp packets are choosing R1's interface s0/1 as exit interface to reach the destination.
But lets say I want EIGRP to Win this race....hmmm...actually there are many ways to achieve this...let me show you my preferred way for this situation.

Lets turn auto-summarization off in EIGRP,because as soon as we will do that, EIGRP will also advertise the 20.0.0.0 network with /24 prefix length. Also remember that in such situation where both routing protocols will have same prefix length for a given destination; AD will take precedence and only routes with lower AD will end up into the routing table. If AD is also same <> than next preference will be lower metric and in last if all matches than traffic will be load balanced equally.
So lets turn off the auto-summarization on both R1 & R2

R1#sh run be router

router eigrp 1

network 3.3.3.1 0.0.0.0

network 10.0.0.1 0.0.0.0

no auto-summary

!
R2(config)#do sh run be router

router eigrp 1

network 3.3.3.2 0.0.0.0

network 20.0.0.1 0.0.0.0

no auto-summary

!

Now lets again take a look at routing table and see no ospf routes are there in routing table:

R1#sh ip route

1.0.0.0/30 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Serial0/1

2.0.0.0/30 is subnetted, 1 subnets

O 2.2.2.0 [110/128] via 1.1.1.2, 00:01:06, Serial0/1

3.0.0.0/30 is subnetted, 1 subnets

C 3.3.3.0 is directly connected, Serial0/0

20.0.0.0/24 is subnetted, 1 subnets

D 20.0.0.0 [90/2195456] via 3.3.3.2, 00:01:06, Serial0/0

10.0.0.0/24 is subnetted, 1 subnets

C 10.0.0.0 is directly connected, FastEthernet0/0

:)
Deepak Arora

CCIE#2xxxx....Oops that number is still missing :)

rfc 1925 - The Twelve Networking Truths

I have to say this is the coolest rfc I have read in my life till date. Also I can assure this time you won't feel sleepy reading rfc :-)
rfc 1925 - The Twelve Networking Truths
1) It Has To Work.
2) No matter how hard you push and no matter what the priority, you can't increase the speed of
light.
(2a) (corollary). No matter how hard you try, you can't make a baby in much less than 9
months.
Trying to speed this up *might* make it slower, but it won't make it happen any quicker.
3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
4) Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
5.) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
6.) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
(6a) (corollary). It is always possible to add another level of indirection.
7) It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
8.) It is more complicated than you think.
9) For all resources, whatever it is, you need more.
(9a) (corollary) Every networking problem always takes longer to solve than it seems like it
should.
(10) One size never fits all.
(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
(11a) (corollary). See rule 6a.
(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Simple Frame-Relay Hub & Spoke Network

Click on image to enlarge it:


Let's discuss about setting up a simple Frame-Relay Hub & Spoke network today. But before getting deep into the configuration let's first discuss about FR(Frame-Relay) hub & spoke requirements and other stuff:

Frame-Relay is a Layer 2 NBMA technology (OSI layer 2 - Data Link). That means it can only provide layer 2 connectivity between routers. Frame-Relay is basically a layer 2 WAN encapsulation just like PPP & HDLC.

Some of the FR terminologies are as mentioned below:

LMI (Local Management Interfaces) - Used between DCE and DTE, manages the connection (signaling messages, keepalive messages).

PVC (Permanent Virtual Circuit) - A predefined VC (equated to leased line)

DLCI (Data-link Connection Identifier) - Frame Relay address used in headers to identify the VC

NBMA (Non Broadcast Multi Access) - Broadcasts not supported, but more than 2 devices can be connected

To setup connectivity between two routers through FR Cloud we need L3 to L2 resolution to occur. That means a mapping/resolution is required between Local router's DLCI and remote router's ip address. This can be achieved in two ways: 1.) Using Inverse ARP 2.) Using Static FR Map Statements.

If the FR network is point to point type than we can go for Inverse ARP option but it's not recommended for Hub & Spoke topology. Now let me show you a simple Hub & Spoke Network configuration. In Hub & Spoke topology Spoke-to-Spoke traffic will always pass through Hub router. Advantage of this design is we need to buy less FR circuits from ISP as topology is not fully meshed. So setup will be cheaper. Disadvantage would be Single point of failure that means if hub router gets failed in that situation no spoke will be able to reach each other.

Config is as below:

R1#sh run int s0/0
Building configuration...

Current configuration : 219 bytes
!
interface Serial0/0
ip address 10.0.0.1 255.0.0.0
encapsulation frame-relay --> Enables Frame Relay encapsulation on WAN interface
frame-relay map ip 10.0.0.2 102 broadcast --> L2 to L3 mappings between local router's DLCI
and Remote router's ip address
frame-relay map ip 10.0.0.3 103 broadcast --> Same as mentioned in previous step
no frame-relay inverse-arp --> Disabling inverse arp as we are using Static FR maps
end

R1#sh frame-relay map
Serial0/0 (up): ip 10.0.0.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 10.0.0.3 dlci 103(0x67,0x1870), static,
broadcast,
CISCO, status defined, active



R1#sh frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 19 Num Status msgs Rcvd 20
Num Update Status Rcvd 0 Num Status Timeouts 0
Last Full Status Req 00:00:13 Last Full Status Rcvd 00:00:13

R2#sh run interface serial0/0
Building configuration...

Current configuration : 209 bytes
!
interface Serial0/0
ip address 10.0.0.2 255.0.0.0
encapsulation frame-relay
clock rate 2000000
frame-relay map ip 10.0.0.1 201 broadcast
frame-relay map ip 10.0.0.3 201 --> No broadcast is included here as it's already enabled for
DLCI 201 by previous static map. So no need to enable
redundant broadcast support.
no frame-relay inverse-arp
end



R3#sh run int s0/0
Building configuration...

Current configuration : 209 bytes
!
interface Serial0/0
ip address 10.0.0.3 255.0.0.0
encapsulation frame-relay
clock rate 2000000
frame-relay map ip 10.0.0.1 301 broadcast
frame-relay map ip 10.0.0.2 301
no frame-relay inverse-arp
end


By Default we cannot ping our FR interface ip address. To make it possible we need local L2 to L3 resolution.

R1#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame map ip 10.0.0.1 102 broadcast
R1(config-if)#ex
R1(config)#do ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/111/148 ms

Best Regards,
Deepak Arora

Handy "sh protocol" command

OK...let me show another handy command "sh protocol". We all know that with the help of "sh ip interface brief" command we can see all the configured interfaces with the ip address and their status. But still we can't determine the configured subnet mast for the interface. So there is a better command to get the entire information along with the subnet mask. I learned this command during my CCNA studies but found that not many people actually know about this handy command. Specially now we can also determine the Network ID of configured ip address and it's subnet information too. So here we go :-)

R1#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.0.1 YES manual up up
Serial0/0 1.1.1.1 YES manual up down
FastEthernet0/1 20.0.0.1 YES manual up up
Serial0/1 2.2.2.2 YES manual up down

R1#sh protocol
Global values:
Internet Protocol routing is enabled
FastEthernet0/0 is up, line protocol is up
Internet address is 10.0.0.1/8
Serial0/0 is up, line protocol is down
Internet address is 1.1.1.1/30
FastEthernet0/1 is up, line protocol is up
Internet address is 20.0.0.1/8
Serial0/1 is up, line protocol is down
Internet address is 2.2.2.2/30
In newer IOS verions & platforms you may also need to add interface name specifically with command to view information:
R1#sh protocol serial 0/0
Serial0/0 is up, line protocol is down Internet address is 1.1.1.1/30
Best Regards,
Deepak Arora

IP Prefix Lists - Few Words

IP prefix-list

ip prefix-list provides the most powerful prefix based filtering mechanism

Here is a quick little tutorial on Prefix-lists for you.

A normal access-list CANNOT check the subnet mask of a network. It can only check bits to make sure they match, nothing more. A prefix-list has an advantage over an access-list in that it CAN check BOTH bits and subnet mask - both would have to match for the network to be either permitted or denied.

For checking bits a prefix list ALWAYS goes from left to right and CANNOT skip any bits. A basic example would be this:

172.16.8.0/24

If there is only a / after the network (no le or ge) then the number after the / is BOTH bits checked and subnet mask. So in this case it will check the 24 bits from left to right (won't care about the last 8
bits) AND it will make sure that it has a 24 bit mask. BOTH the 24 bits checked and the 24 bit subnet mask must match for the network to be permitted or denied.

No we can do a range of subnet masks also that could be permitted or
denyed:

172.16.8.0/24 ge 25

If we use either the le or ge (or both le and ge) after the /, then the number directly after the / becomes ONLY bits checked and the number after the ge or le (or both) is the subnet mask. So in this case we are still going to check the first 24 bits of the network from left to right. If those match we are then going to check the subnet mask, which in this case can be GREATER THAN OR EQUAL TO 25 bits - meaning that as long as the first 24 bits of the network match the subnet mask could be 25,26,27,28,29,30,31,or 32 bits. They would all match.

We can also do:

172.16.8.0/24 le 28

Again this will check the first 24 bits of the network to make sure that they match. Then it will check to make sure that the subnet mask is LESS THAN OR EQUAL TO 28 bits. Now this isn't going to be 28 bits down to 0 bits, the subnet mask can't be any lower than the bits we are checking. So the valid range of subnet masks for this one would be 28 bits down to 24 bits (24,25,26,27,and 28). All of those would match.

We can also do both ge and le:

172.16.8.0/24 ge 25 le 27

Here again we are checking the first 24 bits to make sure they match.
Then our subnet mask must be GREATER THAN OR EQUAL TO 25 bits LESS THAN OR EQUAL TO 27 bits. Meaning that 25,26,and 27 bit subnet masks would match.

Now for a couple of examples:

If we have the following networks:

172.16.8.0/28
172.16.8.16/28
172.16.8.32/28
172.16.8.48/28
172.16.8.64/28

We could permit all of these networks with on prefix-list statement:

172.16.8.0/24 ge 28 le 28

This will check the first 24 bits to make sure they match. All of these networks have 172.16.8 as the first 24 bits, and it won't care what is in the last 8 bits. Then it will check to make sure that the subnet mask is GREATER THAN OR EQUAL TO 28 bits LESS THAN OR EQUAL TO 28 bits - the only number that works for this is 28 bits. So the first 24 bits in the network must match and it has to have a 28 bit subnet mask. All 5 of our networks would match for this.

We could be even more precise with this and use:

172.16.8.0/25 ge 28 le 28

If we take a look at our 4th octects we will see that for all of them the 128 bit is off so we can check that bit also (25 bits total we are checking).

0 -- 0 0 0 0 0 0 0 0
16 - 0 0 0 1 0 0 0 0
32 - 0 0 1 0 0 0 0 0
48 - 0 0 1 1 0 0 0 0
64 - 0 1 0 0 0 0 0 0

This would be closer to permitting the 5 networks that we have.

We could also permit only the classful networks. The first thing that we need to do is figure out exactly what a classful network is.

For a class A network we know that it has to have an 8 bit mask and must be between 0 and 127 in the first octect. If we break down 0 and 127 we
get:

0 --- 0 0 0 0 0 0 0 0
127 - 0 1 1 1 1 1 1 1

For the first octect of a class A network the first bit has to be a 0, it must be off. So we can do a prefix-list like this:

0.0.0.0/1 ge 8 le 8

In our first octet the first bit is a 0 (which is what it would need to be to be class A), with the /1 we have we are ONLY checking the first bit to make sure it's a 0 (meaning it would be a class A network 0 - 127). We are then making sure that this class A network actually has a class A subnet mask of 8 bits, and only 8 bits would match.

For the class B's we need to make sure that they have a 16 bit subnet mask and that they are in the range of 128 - 191 in the first octet. If we break down 128 and 191 we get:

128 - 1 0 0 0 0 0 0 0
191 - 1 0 1 1 1 1 1 1

The first two bits are what we are going to care about. We need to make sure that the first two bits in the first octet are 1 0 . The first number that we can use as our standard we are checking against is 128 -
128 has a 1 0 as the first two bits in its first octet.

128.0.0.0/2 ge 16 le 16

So we are checking the first two bits to make sure the network has a 1 0, meaning that it must be in the range of 128 - 191. We are then going to check to make sure that it has the classful 16 bit mask, and ONLY a
16 bit mask.

Finally we have the class C networks. Class C networks are in the range of 192 - 223 and they must have a 24 bit mask. If we break down 192 and
223 we get:

192 - 1 1 0 0 0 0 0 0
223 - 1 1 0 1 1 1 1 1

The first 3 bits in the first octet are what we care about. 192 would be the first number we can put in that first octect that will have 1 1 0 as its first 3 bits.

192.0.0.0/3 ge 24 le 24

We are going to check the first 3 bits of the octet and make sure that its 1 1 0 meaning that it has to be in the range of 192 - 223 being class C, then we are going to check to make sure it has a class C classful subnet of 24 bits.

Finally how to permit or deny any could be very helpful since a Prefix-list just like an Access-list has an implicit deny at the end:

0.0.0.0/0 le 32

This is 'any' for a prefix-list. It says check 0 bits; I don't care what any of the bits are. It also says that the subnet mask can be 32 bits or less (down to the number of bits we are checking) down to 0. So we aren't going to check any bits and the network can have a subnet mask of anything between 0 and 32 bits. This would be 'any'.

Now for your Prefix-list:

In the 3rd Octet we have 1, 4, and 5. We'll break these down to binary to see if we can summarize these into one line:

1 - 0 0 0 0 0 0 0 1
4 - 0 0 0 0 0 1 0 0
5 - 0 0 0 0 0 1 0 1

For a Prefix-list we need to go from the left to the right and we can't skip bits. So for these three networks we would need to stop at the 8 bit since it is the last bit from left to right that is the same. This would give us 3 bits that are different, or 8 possible networks. We only have 3 of the 8 possible networks and we should not permit or deny more than we actually have. We should be as specific as possible.

If we leave the 91.86.1.0/24 alone by itself it will give us a Prefix-list of:

91.86.1.0/24

This will check the first 24 bits from left to right to make sure that they match, and it will also check to make sure that it has a 24-bit subnet mask.

For the 4 and 5 networks we can permit or deny both of those with one line. If we take a look at 4 and 5 again we can see that all of the bit's match down to the 2 bit. This would leave 1 bit that doesn't match, which would give us 2 possible networks, both of which we have.
The Prefix-list to permit or deny both 4 and 5 would be:

91.86.4.0/23 ge 24 le 24

This will check the first 23 bits from left to right. The 24th bit could either be off, which would give us 4, or it could be on which would give us 5. Since we have the ge and le involved the /23 is only bits checked. The ge and le specify that our subnet mask must be greater than or equal to 24-bits and less than or equal to 24-bits which means that the subnet mask must be 24-bits for both possible networks.

Best Regards,
Deepak Arora

PIX - "sh block" command

I would like to thank Mr. Don Edelmon who shared this helpful information with us. DON is a Network Security Specialist working for xxxxx :-)

Anyways below is the information:

When the PIX boots, it copies the OS from Flash into RAM and runs the OS from RAM (just like routers
do). Next, the PIX copies the its startup configuration from Flash and places it into RAM.

Finally, the PIX carves out RAM to create the block pools. Once this is completed, the PIX is up and
running and need additional RAM only if the configuration increases in size. In addition, the PIX
stores the translation and connection entries in RAM. During normal operation, the free memory on
the PIX should change very little, if at all.

Typically, the only time you should run low on memory is if you are under attack and there are
hundreds of thousands of connections going through the PIX. You can check this by issuing the show
conn count command, which will display the current and
maximum number of connections through the PIX.

The 'show block' command will change during normal operation in the PIX...
For example... When a packet comes into a PIX's interface, it is placed on the input interface
queue, passed up to the OS, and placed in a block. For Ethernet packets, the 1550-byte blocks are
used; if the packet comes in on a 66 MHz Gigabit Ethernet card, the 16384-byte blocks are used. The
PIX determines whether the packet should be permitted or denied based on the Adaptive Security
Algorithm (ASA) and processes the packet through to the output queue on the outbound interface. If
the PIX is having trouble keeping up with the traffic load, the number of available 1550-byte blocks
(or 16384-byte blocks for 66 MHz GE) will hover close to 0 (as shown in the CNT column of the
command output). When the CNT column hits zero, the PIX attempts to allocate more blocks, up to a
maximum of 8192. If no more blocks are available, the PIX drops the packet.

The 256-byte blocks are mainly used for stateful failover messages. The active PIX generates and
sends packets to the standby PIX to update the translation and connection table. During periods of
bursty traffic where high rates of connections are created or torn down, the number of available
256-byte blocks may drop to 0. This indicates that one or more connections were not updated to the
standby PIX. This is generally acceptable, because the stateful failover protocol will catch the
missing xlate or connection the next time around. If the CNT column for 256-byte blocks stays at or
near 0 for extended periods of time, however, then the PIX is having trouble keeping the translation
and connection tables synchronized because of the number of connections per second that the PIX is
processing. If this happens consistently, you should consider upgrading the PIX to a faster model.
Syslog messages sent out from the PIX also use the 256-byte blocks, but they are generally not
released in such quantity to cause a depletion of the 256-byte block pool. If the CNT column shows
that the number of 256-byte blocks is near 0, ensure that you are not logging at Debugging (level 7)
to the syslog server. This is indicated by the logging trap line in the PIX configuration. It is
recommended to set logging at Notification (level 5) or lower, unless you require additional
information for debugging purposes.

Example
pixfirewall# show blocks
SIZE MAX LOW CNT
4 1600 1597 1600
80 400 399 400
256 500 495 499
1550 1444 1170 1188
16384 2048 1532 1538

The following describes the columns in the show blocks output.
Column Description
SIZE = The size, in bytes, of the block pool.
MAX = The maximum number of blocks available for the specified byte block pool. Note that the
maximum number of blocks are carved out of memory at bootup. Typically, the maximum number of blocks
does not change. The exception is for the 256- and 1550-byte blocks, where the PIX can dynamically
create more when needed, up to a maximum of 8192.
LOW = The low water mark. This is the lowest number of this size blocks
available since the PIX was powered up, or since the last clearing of the
blocks (with the clear blocks command).
CNT = The current number of blocks available for that specific size block
pool.
The following describes the rows in the show blocks output.

Here is the documentation on the Interfaces and Memory blocks I mentioned to you.
Memory blocks.

Even though this is a little garbled you just need to know what the block size is used for.
Block Size Used to MAX Created at Startup
4 Duplicating existing blocks in DNS, isakmp, url-filtering, uauth, h323, tftp, and TCP
Modules1600
80 Used in TCP Intercept to generate an ACK packet, fover hello messages. 400400
256 Stateful Failover, Syslog, TCP module
1550 Ethernet Packets, buffering url filtered packets.8192400
1552 QoS Metrics 40960
2560 IKE Messages 81920
4096 QoS Metrics 2000
8192 QoS Metrics 1500
16384 Only used for the Livengood (i82543 ) Gig Ethernet cards 92160
65536 QoS Metrics160

Handy Show Run Linenum Command !!!

Yesterday while going through Cisco Doc CD I came to know about another handy command which can be very helpful in some situations so I through lets share it with you guys. The command is "sh run linenum full". What this does is add a sequence number before each line of Running-Configuration. This could be helpful in situation like when we are discussing some configuration over the phone call and can tell the person on the other side to look at specific line in the configuration to discuss and he can easily find that line through it's sequence number :-)

Router#sh run linenum full
Building configuration...

Current configuration : 575 bytes
1 : !
2 : version 12.4
3 : service timestamps debug datetime msec
4 : service timestamps log datetime msec
5 : no service password-encryption
6 : !
7 : hostname Router
8 : !
9 : boot-start-marker