Route Maps and Access-Lists
Sunday, 7 June 2009
I received an email from one of the readers, Joel, who is getting confused as to how access-lists and route-maps work together. I have therefore created this topic to cover the very basics of access-lists and how they link into route-maps. In turn I have expanded the lesson on route-maps to cover a little more of the nuances of route-map theory as well as an aid to other readers.
Access-lists contain very simple logic. Lists 1-99 (standard access-lists) will permit or deny all IP traffic from a particular source whereas access-lists 101-199 (extended access-lists) extend this functionality allowing you to permit/deny with more granularity, for example, specifying both source and destination address, Layer 4 protocols and port number (i.e. TCP/UDP), and Layer 3 protocols other than IP (i.e. ICMP).
The syntax for standard access-lists is as follows:
"I wish to permit all IP traffic from host [host-ip-address]"
"I wish to permit all traffic from [subnet] [wildcard-mask]"
"I wish to deny all IP traffic from host [host-ip-address]"
"I wish to deny all traffic from [subnet] [wildcard-mask]"
An example is you want to allow all IP traffic from 192.168.1.0/24. The access-list is simple:
access-list [1-99] permit 192.168.1.0 0.0.0.255
The syntax for extended access-lists is slightly different:
"I wish to [permit/deny] [type-of-traffic] going from [source-address] [source-wildcard-mask] to [destination-address] [destination-wildcard-mask] [optional port-number]"
Let's say you would like to permit all Telnet traffic going from 192.168.1.0/24 to a device at 192.168.2.1.
Telnet uses TCP port 23 and here is how you would write the extended access-list:
"access-list [101-199] permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23"
In English, this access-list permits TCP from 192.168.1.0/24 to the host whose address is 192.168.2.1 where the TCP port number is 23.
How to apply access-lists to route-maps
Believe me there is nothing tricky about doing this. A route-map is a way of influencing the routing decision made by a routing device. The basic syntax of a route-map is as follows:
route-map [route-map-name] [permit/deny] [sequence-number]
match [condition]
set [what-you-want-to-do-with-the-packet-if-it-matches-the-match-criteria]
As you build up your route-map you simply increase the sequence number for each match you want to do. Once you have created your route-map you must then apply it to a router interface e.g.
int fa0/0
ip policy route-map [route-map-name] [in/out]
Let's step back up to the match criteria. There are a number of things that we can match on but what we will focus on is how we can influence traffic flows through a router. We do this by using the match ip address [access-list-number] command. The extended access-list in my earlier example called for allowing Telnet traffic from 192.168.1.0/24 to be able to reach host 192.168.2.1. Let's take that example a bit further and say that we want to make all Telnet traffic going from 192.168.1.0/24 to host 192.168.2.1 which has entered my router's fa0/0 interface to leave my router's Serial0/0 interface. We could use that access-list and apply it to our route-map (I've called it MYMAP):
access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
int fa0/0
ip policy route-map MYMAP in <---applies the MYMAP route-map inbound on fa0/0
How does the router service the route-map?
Actually it is very logical. The router starts at the lowest sequence number until it finds a match.
So let's run through it. A host at 192.168.1.1 tries to Telnet to 192.168.2.1 and the packet is received on fa0/0 of our router. Our router, looking at fa0/0, realises that policy-based routing is required and that it should look at the route-map named MYMAP in order to make a decision on how to forward the traffic. The router starts at the lowest sequence number in the route-map and checks the match criteria. The example above tells the router to check access-list 101. The packet received matches access-list 101 so the router returns to the route-map and checks what the set command tells it to do. The set command tells it to forward this traffic out of Serial0/0
What if there is no match found?
If there is no match then the router will route the packet based on the contents of the routing table. If a host at 192.168.3.1 tried to Telnet to 192.168.2.1 and the packet is received through fa0/0 of our router, the router will look into MYMAP, then at access-list 101, realise that access-list 101 does not match 192.168.3.1 as a source address and will return to the route-map looking for the next highest sequence number. In our example there is not another sequence number so the router will simply forward the traffic based upon the contents of its routing table (i.e. what it would do if there was no route-map applied to the fa0/0 interface).
How could we use route-maps to drop traffic?
Chris, you've just told us that if no match is found then the packet will be forwarded by the contents of the routing table so how can I influence that?
Generally, you would drop traffic on an interface using an access-list applied directly to the interface, however, it can be done using a route-map. Let's say you want to have control over all traffic coming in on fa0/0 of our router and want to drop anything that doesn't match our defined criteria. Let's say I have created access-lists 101-105 which specifies my criteria. My route-map would look as follows:
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
route-map MYMAP permit 20
match ip address 102 <---this line refers to access-list 102
set interface Serial0/1
route-map MYMAP permit 30
match ip address 103 <---this line refers to access-list 103
set interface Serial0/2
route-map MYMAP permit 40
match ip address 104 <---this line refers to access-list 104
set interface Serial0/3
route-map MYMAP permit 50
match ip address 105 <---this line refers to access-list 105
set interface Serial0/4
Now I want to deny everything else. Remember the Null0 interface, what I like to call Packet Heaven (as that is where packets that need to be dropped/die go)? Check this route-map statement out:
route-map MYMAP permit 60
set interface Null0
Whoa Chris! What did you do there? Where has the match statement gone? The beauty is you don't need it. Sure, you could configure an access-list (e.g. access-list 106 permit ip any any) and have:
route-map MYMAP permit 60
match ip address 106
set interface Null0
But there really is no need. If the route-map evaluation has got this far we are just saying "drop everything else, send it to Packet Heaven, Null0". By removing the match statement you are in effect creating a catch-all statement. Equally, you may have wanted all traffic not matching access-lists 101-105 to be routed out of Serial0/5 rather than be routed using the routing table or dropped. Your last route-map clause would have been:
route-map MYMAP permit 60
set interface Serial0/5 <-- all traffic not previously matched will go via Serial0/5
Other Key Points About Route-Maps
1. The route map statements can also be marked with a deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed). Only if the statement is marked as permit and the packets meet the match criteria are all the set clauses applied. If the statement is marked as permit and the packets do not meet the match criteria, then those packets are also forwarded through the normal routing channel.
2. There can be multiple match criteria on the same line where only ONE of the criteria has to match. There can be multiple match statements on different lines where ALL match statements must match. I think an example here is in order:
route-map MYMAP permit 10
match ip address 101 102 103 104
match ip address 105
set interface Serial0/0
The logic here works thus:
match ip address 101 OR 102 OR 103 OR 104
AND
match ip address 105
So a packet comes in and matches access-list 104, the router then goes on to check access-list 105. If the received packet also matches access-list 105 then the set command is used. If the packet had failed to match access-list 105 then the next statement in the route-map would be evaluated or the packet would be forwarded normally.
3. There are other match criteria such as packet length but I'll focus on the other set criteria.
set ip next-hop [next-hop-ip-address] - specifies where to send the packet. Preferable to use this rather than exit interface.
set default interface [interface] - If there is no entry in the routing table for the destination of this packet route it through the specified interface
set default ip next-hop [next-hop-ip-address] - if there is no entry in the routing table for the destination of this packet route it via the specified next-hop
Notice the use of the "default". This is only true if there is no corresponding entry in the routing table.
4. Like match statements, you can have multiple set statements too. Again, an example will help illustrate this.
route-map MYMAP permit 10
match ip address 101
set interface Serial0/0 Serial0/1
By default any matches to access-list 101 will exit Serial0/0 but if that fails Serial0/1 will be used as the exit interface.
Conclusion
Like everything, route-maps are easy once you understand how the syntax works. Any questions or feedback please feel free to leave comments and/or email me using the Contact Me tab at the top of the screen. Good luck to you all in your studies!
Posted byChris Bloomfield at 18:07 16 comments
Labels: access, access-lists, Cisco, extended, network, Route Summarization, route-map, route-maps, standard
Vyatta on VM Workstation
Monday, 15 December 2008
Here's the deal. How do you fill your work time looking busy but having a bit of fun? Simple. Look out for emerging technologies and tell your department you want to "innovate" with Product X. So here I am, looking at Vyatta. Bold claims from these guys but is it as good as they say? Well I'm not here to run the mathematical experiments. What I want to know is "Is it easy to use?" and "Can I use it in one of our projects?". It's early days to be answering the latter but I may be able to answer the former over a series of posts.
What I want to do is set up a dummy network in VM Workstation to simulate a square with a Vyatta router at each corner like so:
Vyatta Instance 1 --> Vyatta Instance 2
Vyatta Instance 1 --> Vyatta Instance 3
Vyatta Instance 2 --> Vyatta Instance 4
Vyatta Instance 3 --> Vyatta Instance 4
I really am a noob to VM Workstation but after a little playing around I got it to work.
Taking the above connections I used the Custom Network Connections for each (I believe VMNet0 and VMNet1 are reserved):
Vyatta Instance 1 --> Vyatta Instance 2 = VMNet2
Vyatta Instance 1 --> Vyatta Instance 3 = VMNet3
Vyatta Instance 2 --> Vyatta Instance 4 = VMNet4
Vyatta Instance 3 --> Vyatta Instance 4 = VMNet5
By default each virtual machine in VM Workstation has one Network Connection set up (usually NAT). Modify this to a custom connection and from the drop-down list choose the appropriate VMNet. To add a new Network Adapter simply click Add in the Virtual Machine Settings and choose Network Adapter then select Custom and choose the desired VMNet connection. For my example above I modified the first Network Adapter on Vyatta Instance 1 to VMNet2 and created a new Network Adapter in VMNet3. I done similar on the other three instances and lo-and-behold everything was connected.
Here's my basic settings:
Vyatta Instance 1:
configure
set system host-name Vyatta-Instance-1
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2
set interfaces ethernet eth0 address 192.168.2.1/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3
set interfaces ethernet eth1 address 192.168.3.1/24
commit
save
Vyatta Instance 2:
configure
set system host-name Vyatta-Instance-2
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1
set interfaces ethernet eth0 address 192.168.2.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4
set interfaces ethernet eth1 address 192.168.4.1/24
commit
Vyatta Instance 3:
configure
set system host-name Vyatta-Instance-3
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1
set interfaces ethernet eth0 address 192.168.3.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4
set interfaces ethernet eth1 address 192.168.5.1/24
commit
Vyatta Instance 4:
configure
set system host-name Vyatta-Instance-4
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2
set interfaces ethernet eth0 address 192.168.4.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3
set interfaces ethernet eth1 address 192.168.5.2/24
commit
This is probably more for my reference but to undo anything use the "delete" command. For example if I accidentally put an IP address under eth0 for example I could use the following;
delete interfaces ethernet eth0 address 192.168.3.1/24
Now I've decided to run RIP just to see how easy it is.
Vyatta Instance 1
configure
set protocols rip network 192.168.2.0/24
set protocols rip network 192.168.3.0/24
commit
save
Vyatta Instance 2
configure
set protocols rip network 192.168.2.0/24
set protocols rip network 192.168.4.0/24
commit
save
Vyatta Instance 3
configure
set protocols rip network 192.168.3.0/24
set protocols rip network 192.168.5.0/24
commit
save
Vyatta Instance 4
configure
set protocols rip network 192.168.4.0/24
set protocols rip network 192.168.5.0/24
commit
save
To shut down an interface:
set interfaces ethernet eth0 disable
To bring it back up:
delete interfaces ethernet eth0 disable
It all seems easy so far.
Posted byChris Bloomfield at 11:23 1 comments
Labels: Cisco, machine, virtual, VM workstation, VMware, vyatta
GNS3 Configuration Guide - Linux (Fedora 9)
Thursday, 4 December 2008
I've been hearing how much better Linux is to Windows from guys across the world so I thought I would install FC9 on my home computer and promptly destroyed Windows XP. What a blessing in disguise! Now I've made the leap of faith I am one happy man although still a little green to the world of Linux.
Let's get to installing GNS3, VPCS, loopback adapter equivalent bridge interfaces etc. I'm going to do this without pictures as for the majority of the case it is exactly the same as the Windows installation. It is just the initial installation and dependencies that are required.
Note to purists: I am a Linux noob so if my terminology is out then I apologise.
Note the use of sudo here. If you haven't set it up then you can log in as root and repeat the command (without the "sudo" prefix).
1. Install PyQt4
Fedora = sudo yum -y install PyQt4
Ubuntu = sudo apt-get install PyQt4
This should install all dependencies needed for GNS3 including SIP.
2. Install tunctl and bridge-utils e.g. sudo yum -y install tunctl bridge-utils
This will now allow you to create bridged interfaces equivalent to Microsoft Loopback Adapters.
3. Download GNS3 from here. I tend to go for the tgz file.
4. Download Dynamips from the same location under the heading Associated Software. I run 32-bit only so I download the Dynamips 0.2.8-RC2 binary for Linux x86 platforms
5. Right-click the downloaded GNS3 file and choose Extract Here. Drag the Dynamips file downloaded in Step 4 to the extracted folder. Now right-click the Dynamips file and select the Permissions tab and ensure the "Allow executing file as program" box is ticked, then click Close.
6. Now double-click the gns3 file and choose Run. Assuming that all dependencies have been installed you should see GNS3 start with the screenshot in Step 3 of my GNS3 Windows guide. Follow the majority of that to set up the images and working directories plus the idlepc value.
So hopefully now you should be able to muck around with GNS3 and do most of what you need to do. However, I had one main issue and that was how do I connect my router to my local machine so that I could run syslog servers, iperf, and other apps like we do using the Loopback Adapter in Windows? Well I have to pay my respects to tuner_x at the Sadikhov IT forums for the guide on how to do this. You must run GNS3 as root in order to achieve this so for example I run:
sudo ./Chris/Desktop/GNS3-0.5-src/gns3
NOTE: If Dynamips doesn't start (you'll probably notice that you cannot connect to a hypervisor on 7200 when dragging a router onto the stage) as root then you need to either clean the working directory as it points to your user account or point the working directory to a new location.
1. If you didn't do this before you need to install tunctl and bridge-utils as outlined in Step 2 of the initial configuration guide above.
2. Now add the following to the script below so each time you switch on your PC the bridge interfaces are created.
sudo vi /etc/rc5.d/S99local
Now insert the following (note that there is no particular naming convention, just what I chose to do) and save:
# Script to create bridge interfaces. Requires tunctl and bridge-utils to be
# installed.
#
# This creates the interfaces. -t names the interface and -u sets the owner of
# of the interface.
/usr/sbin/tunctl -t fed_0 -u Chris
/usr/sbin/tunctl -t fed_1 -u Chris
/usr/sbin/tunctl -t gns3_0 -u Chris
/usr/sbin/tunctl -t gns3_1 -u Chris
# Then bring the interfaces up
/sbin/ifconfig fed_0 up
/sbin/ifconfig fed_1 up
/sbin/ifconfig gns3_0 up
/sbin/ifconfig gns3_1 up
# Now create the bridge interface
/usr/sbin/brctl addbr gns3_br0
/usr/sbin/brctl addbr gns3_br1
# Bring the bridge interfaces up
/sbin/ifconfig gns3_br0 up
/sbin/ifconfig gns3_br1 up
# Add the tap interfaces to the bridge interfaces
/usr/sbin/brctl addif gns3_br0 fed_0
/usr/sbin/brctl addif gns3_br0 gns3_0
/usr/sbin/brctl addif gns3_br1 fed_1
/usr/sbin/brctl addif gns3_br1 gns3_1
# Here is an example of how to assign an IP address to the gns3_br0 interface so one
# can ping from a GNS3 router to the local machine in order to run syslog etc
#
# ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up
#
# I do this manually and not via the script but keep it here for reference only.
# And that's it
Now you could choose to reboot or restart the appropriate services. I tend to restart the services as it is quicker than rebooting.
sudo /etc/rc5.d/S99local restart
sudo /etc/init.d/network restart
Now add an IP address to one of your gns3 bridge interfaces. Here I am using the first:
sudo ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up
NOTE: Do not use the same IP address as your main ISP router otherwise you'll knock out your Internet connection. D'oh! Always learn the hard way don't you Chris? LOL.
Go into GNS3 and drag a cloud, or a customised symbol, onto the stage and right-click and choose Configure. Select the "NIO TAP" tab and type the name of your bridge interface (e.g. gns3_br0) then click Add, Apply, then OK.
Hook your router up to the cloud, start the IOS, console into your router, and put the interface into the same subnet as your bridge interface. Bring the interface up and lo-and-behold you should have connectivity between your PC and your router.
What about multiple hosts? You can still use VPCS as explained in my VPCS Configuration Guide for Windows although there is a slightly different way to run it.
1. Once you have downloaded the file, extract it to your GNS3 folder.
2. Now open the extracted folder and locate the "vpcs" file (NOT vpcs.exe).
3. Right-click the vpcs file and choose the Permissions tab and tick the box next to "Execute".
4. Go to the desktop and right-click and choose Create Launcher.
5. Type = Application in Terminal
6. Name = VPCS
7. Command = the path to the vpcs file located in Step 2.
8. Comment = Virtual PCs
9. Click OK to create the launcher
10. Drag the launcher into the VPCS folder.
When you want to run VPCS just double-click on the created launcher. The configuration works just as it does in Windows.
That's it. FC9 running GNS3 exactly as I had it on Windows.
I hope it helps you Linux noobs to run GNS3.
Chris
Posted byChris Bloomfield at 13:36 3 comments
Labels: brctl, bridge-utils, dynamips, FC9, Fedora, Fedora 9, gns3, linux, tunctl, vpcs
GNS3 0.5 released
Thursday, 19 June 2008
The GNS3 0.5 release is available. It includes bugs fixes and new features:
* Possibility to load .net files of other users (provided that there is a registered IOS image with the same model as the one used in the NET file).
* New detailed tooltips for nodes.
* A minimalist wizard raised when the configuration file is empty.
* A button to insert a picture on the scene.
* Decorative node support for creating network diagrams.
* Ghostios is now supported on remote hypervisors.
* A symbol manager with library support (a howto to create a symbol library will be released).
* Z values can be changed for annotations and inserted pictures.
* Automatic load-balancing on external hypervisors (choose multiple external hypervisors when recording an IOS image).
* New option to bind the hypervisor manager with an address/name other than 'localhost': useful for labs which use local and remote hypervisors.
* The DMG package includes two Dynamips binaries, one for Tiger and one for Leopard
You will notice that on opening GNS3 for the first time you will now be confronted with a setup wizard which takes you through the first few steps of my main guide.
Clicking on Step 1 will bring you to the following screen:
Clicking on Step 2 will bring you to the following screen:
Posted byChris Bloomfield at 14:14 0 comments
Labels: dynagen, dynamips, gns3, gns3 0.5, ios
Adding Hosts/PCs to GNS3 - VPCS Configuration Guide
Tuesday, 3 June 2008
For some time now I have been asked how I simulate hosts in GNS3 and my stock answer was to configure a router as a host by issuing the "no ip routing" command and setting a default gateway with the "ip default-gateway" command. You would also need to assign an IP address to the interface connected to the router performing routing, or a switch which in turn is connected to a router doing the routing. It worked a treat but had one major flaw, namely, CPU overhead.
I know that a lot of people tried putting loopback adapters at either end of a topology but when pinging between multiple loopback adapters the traffic stayed on the PC and would not pass through the routers configured in GNS3.
By jove though, a clever man, mirnshi I believe his name is, has devised a great little program that can simluate up to 9 hosts within GNS3. It is called VPCS and can be downloaded from here.
In my traditional style I shall run you through a step-by-step guide of configuring VPCS and show you an example of how I set up a basic topology to test the functionality.
1. Download the zip file from here and extract it to wherever desired.
2. Go to the GNS3/Dynamips directory and rename the cygwin1.dll file to cygwin1.dll.old and copy the cygwin1.dll file in the VPCS directory to this directory.
3. Open up a command prompt and change the directory to where you have the VPCS folder. If you are unsure of how to do this, go to Start-->Run and type in "cmd" (without the quotes) and hit Enter. Now using Windows Explorer go to the folder where VPCS is located and copy the location from the address bar. If you cannot see the address bar go to View-->Toolbars and click Address Bar. Now go back to the command prompt you opened and type "cd" (again, without the quotes) followed by the path to your VPCS folder. For example, I may have cd C:\Program Files\GNS3\vpcs-0.14g
An even easier way to do this in Windows XP is to download the "Open Command Prompt Here" Power Toy from here.
Once installed right-click the VPCS folder and select Open Command Prompt Here and a command prompt window will open in that directory. Windows Vista includes this ability right out of the box, it's just not immediately obvious, because it's hidden behind a shortcut key. To activate this, just hold down the Shift key when you right-click on a folder, and you should see the Open Command Window Here menu item.
4. To run VPCS type vpcs.exe from the command line and you ought to see a screenshot similar to below:
5. Type in the show command to view a printout of your virtual PCs.
6. To view the help type ?
I don't know who Mike Muuss is by the way, lol.
7. To change the IP address and default gateway to better suit your needs the following syntax prevails:
ip [ip address of PC] [ip address of default gateway] [mask in number of bits]
For example:
8. To change the virtual PC you are configuring simply enter the number of the virtual PC you wish to configure.
9. Keep adding as many PCs as you need and configure the IP addresses as desired (limited to 9).
10. Make a note of the LPORT and RPORT settings (from the show command) for each PC you have configured as you will need them for later.
Now the proof of the pudding is in the eating so what I'm going to do is connect a very simple network in GNS3 (I know this seems obvious but KEEP VPCS RUNNING):
NOTE: Each PC is a separate cloud.
11. Right-click on each cloud, choose Configure and then select the NIO UDP tab. You should now see a screen similar to the following:
12. Referring to step 10 where you noted the LPORT and RPORT values for each PC you need to add the RPORT value to the Local Port field in GNS3, the IP address 127.0.0.1 in the Remote Host field in GNS3, and finally the LPORT value in the Remote Port field in GNS3. Once you have finished this ensure that you click on the Add button and select Apply, then OK. For example if my LPORT value was 20000 and my RPORT value 30000 then I would fill it out thus:
13. Now connect your network in GNS3 end-to-end and assign IP addresses as apt to the routers. Remember to either run a routing protcol between the two routers or use static or default routes. For my purpose I used default routes on each router pointing to the other router.
For example in my IP addressing scheme I have:
PC1 to R1 Fa0/0 = 192.168.1.1/24 and 192.168.1.254/24 respectively
R1 Fa0/1 to R2 Fa0/1 = 192.168.0.1/24 and 192.168.0.2/24 respectively
R2 Fa0/0 to PC2 = 192.168.2.254/24 and 192.168.2.1/24 respectively
My default routes are:
R1: ip route 0.0.0.0 0.0.0.0 192.168.0.2
R2: ip route 0.0.0.0 0.0.0.0 192.168.0.1
My network looks like this now:
14. Go back to VPCS. Here I have tested for end-to-end connectivity by pinging from PC1 to PC2:
"So what?" I hear you cry. I know this doesn't prove whether the traffic passes over the GNS3 routers. That is where we use the tracert command in VPCS. Check it out:
Would you look at that! Hop 2 is the Fa0/1 interface of R2. Proof that the packets traverse the routers.
I must say that this is a major breakthrough for me and hopefully for others and will save a lot of time and CPU resources.
Enjoy!
Chris
Posted byChris Bloomfield at 11:09 34 comments
Labels: cygwin, gns3 dynamips, host, loopback, mirnshi, pc, vpcs
Complex Route Summarization
Thursday, 17 April 2008
I've already posted about route summarization but I found this interesting technique for calculating complex route summaries at http://www.sadikhov.com/forum from member MarkinManchester. Thanks Mark!
Sometimes you are asked to filter a complex set of routes using as few lines as possible. Here we will examine a way to calculate the subnet and wildcard for such a scenario. With some practice, you should be able to calculate any set in 5 minutes or less. It is also recommend to test your results in a lab setting, using loopbacks and distribute-lists.
For example, say we are asked to filter the following routes using a one-line filter:
102.17.63.0
126.22.61.0
111.22.57.0
125.33.101.0
First, make a table as shown:
Then, enter the decimal digits from the first octet in the left-hand column. Convert each number to binary. You can use Windows Calculator set to Scientific Mode to do the conversion if you so wish.
In the binary area, first check the octet then column by column, apply the following rules:
- If the entire octet is 0, the subnet is 0 for that octet, and the mask is 255 for that octet.
- Else If the column is all 0’s, the subnet is 0, and the mask is 0
- Else If the column is all 1’s, the subnet is 1, and the mask is 0
- Else the column is a mixture of 1’s and 0’s, the subnet is 0, and the mask is 1.
For the first octet the table should look like:
Convert the binary Subnet and Wildcard Mask to decimal to complete the table:
So far, our filter looks like: 100.xxx.xxx.xxx 27.xxx.xxx.xxx
For the second octet the completed table should look like:
Our summary address now looks like: 100.0.xxx.xxx 27.55.xxx.xxx
For the third octet the completed table should look like:
Our summary address now looks like: 100.0.33.xxx 27.55.94.xxx
Now the last octet for all addresses is zero so the subnet address must be 0 in the last octet and the wilcard mask must be 255 in the last octet.
Our completed summary address looks like: 100.0.33.0 27.55.94.255
Apply this technique as you wish, for example:
access-list 1 permit 100.0.33.0 27.55.94.255
This is a great technique for reducing something complex into easier computation so hats off to Mark again for turning me on to this.
Posted byChris Bloomfield at 19:47 5 comments
Labels: complex, Route Summarization, Summarisation, summary routes, Supernetting, wildcard
GNS3 PEMU Configuration Guide - latest version 0.4.1
Thursday, 3 April 2008
The latest version of GNS3 (0.4.1) offers:
* A dynamic mode (no design/emulation modes)
* A new .net save/load.
* c1700 and WICS support.
* PIX emulation.
* Dynamips's ATM bridge.
* Capture feature for links from the GUI.
* IDLE PC calculation from the GUI.
* GUI improvements (save the window state when closing GNS3 ...)
* Annotation feature.
* Project feature (you can keep router configs, nvram ...)
* NULL NIO support.
* PDF export.
* New languages.
For those that need to set up GNS3 for the first time, I have amended my GNS3 Configuration Guide based on version 0.3.x so that users of 0.4.x can understand and follow it too.
Anyway, back to the stand-out new feature - PIX emulation, yay! My only minor gripe is that PIX is now EOL but as there are loads of PIX firewalls out there I'm not complaining.
Hopefully you can tell but I'm not the kind of guy to leave people in the lurch and chuck them in the deep end so here is a step-by-step guide on how to configure a PIX firewall in the latest version of GNS3.
1. Download and install the latest version of GNS3 from http://www.gns3.net/download and ensure that you install the PEMU wrapper (this is done by default when installing GNS3).
2. Open up GNS3 and you will see a screen like the following (notice how it has changed from the old version, especially that you run the IOS and console to devices from the one screen).
3. Now go to Edit on the menu bar and select Preferences. You will now see the screen below:
4. Now select the PEMU option from the left-hand menu to be presented with a screen like the one below. All you need to do now is point to the PIX Image where it says "PIX Image". Once you have done that click on Apply, then Close.
5. Now drag and drop a PIX firewall from the left-hand menu of the main screen onto the centre stage. Right-click on the firewall and select Start then Console:
6. You should now see your Console session to your PIX firewall as below:
Posted byChris Bloomfield at 11:26 4 comments
Labels: Cisco, configuration, dynagen, dynamips, firewall, gns3, ios, pemu, pix, router
