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
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 briefInterface 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 protocolGlobal values: Internet Protocol routing is enabledFastEthernet0/0 is up, line protocol is up Internet address is 10.0.0.1/8Serial0/0 is up, line protocol is down Internet address is 1.1.1.1/30FastEthernet0/1 is up, line protocol is up Internet address is 20.0.0.1/8Serial0/1 is up, line protocol is down Internet address is 2.2.2.2/30In newer IOS verions & platforms you may also need to add interface name specifically with command to view information:R1#sh protocol serial 0/0Serial0/0 is up, line protocol is down Internet address is 1.1.1.1/30Best Regards,Deepak Arora
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
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
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
Click on image to enlarge it:
