Friday, May 28, 2010

EIGRP No Auto Summary Command, Part 1

In my previous post about EIGRP Route Advertisements I touched on the "no auto-summary" command, but did not delve in to the details of what this command actually does, so today I will.

In a nutshell (see Part 2 for a more detailed explanation), when using EIGRP the "auto-summary" command (which is enabled by default), what happens is that the router automatically creates summary routes for all of the networks which you specify in your EIGRP configuration (with the "network" command). And these aren't good summary routes either - they are routes which are summarised to their classful boundary.

For example, if you issue the following command:

network 10.45.100.0 0.0.0.255

Instead of advertising the network as 10.45.100.0 /24, the router will advertise the entire 10.0.0.0 /8 network instead. To prevent this from happening (which just about everyone does these days), you must issue the following command:

no auto-summary

To see what type of "damage" can be caused by leaving the default "auto-summary" command enabled, please read on.

Here is the topology I'll be using to demonstrate:


As you can see this is a pretty straight forward network. Here is a brief summary of how it is configured:
  • All routers are running EIGRP (AS10)
  • There are EIGRP neighbor adjacencies between each point-to-point link (R4 to R1, R1 to R2, R2 to R3) - This means all routers will share their routing table information with one another
  • All routers have the "auto-summary" command applied to their EIGRP AS10 configuration
Now because all of the routers are sharing their routes with one another you would expect to be able to ping from R4 all the way through to R3, wouldn't you? Well, unfortunately that is not the case at the moment:   

R4#ping 10.16.0.2

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

To troubleshoot this issue, let's take a look at the routing table on R4:

R4:
10.0.0.0/24 is subnetted, 1 subnets
C 10.45.100.0 is directly connected, FastEthernet0/1
D 192.168.0.0/24 [90/307200] via 10.45.100.1, 00:17:31, FastEthernet0/1

As you can see, R4 knows how to get to the 10.45.100.0 network (because it is directly connected) and the 192.168.0.0 /24 network but it has no idea how to get to the 10.16.0.0/24 network. To find out why, let's take a look at the next hop router, R1. Here is the output of R1's "show ip route" command:  

R1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:03:15, Null0
C 10.45.100.0/24 is directly connected, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/0

As per the blue line above, it looks like we may have found part of the issue. The reason why R4 cannot get to R3 could be because R1 is advertising a summary route for the entire 10.0.0.0 /8 range. Why is it doing this you ask? Because R1 is automatically summarising the 10.45.100.0 network to its classful boundary and then passing the advertisement on to R2. What makes matters worse is the fact that when summary routes are used, the router which creates the summary points the network to its Null0 interface. In other words, if R1 does not have a more specific to 10.0.0.0 networks, it will drop the traffic. This explains why when R4 tries to reach R3, it can't.

However, R1 is not entirely to blame. This is because its summary route, if it were the only summary route in the network, would in fact allow the pings to work. It wouldn't be an ideal setup, but it would work.

Unfortunately though, it is not the only summary route in the network. If we take a look at R2's routing table, we will see that it too has a summary route for the exact same range:

R2: 
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:07:18, Null0
C 10.16.0.0/24 is directly connected, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/0

So what does this mean you ask? The problem is that both R1 and R2 believe that they can get to the entire 10.0.0.0 /8 range themselves and therefore they don't need each other. However, this is incorrect because R1 has access to the 10.45.100.0 /24 subnet and R2 has access to the 10.16.0.0 /24 subnet, so they do in fact need each other. Unfortunately though, as their summary routes point to Null0, when they are asked to reach a 10 network they don't have a more specific route for, they drop the traffic.

Looking at R1 and R2's routing tables above, we can see that they have more specific routes to the 10.45.100.0 /24 and 10.16.0.0 /24 networks respectively. This means that R1 won't drop traffic destined for 10.45.100.0 /24 and R2 won't drop traffic destined for 10.16.0.0 /24, however, they will both drop traffic destined for all other 10.0.0.0 networks as they don't have any more specific routing table entries to use.

To remedy this situation, one of the routers is going to have to give up their summary route (ideally though, both of them would). By stopping one of the routers from advertising the summary route, both routers will end up advertising different routes as opposed to identical summary routes.

Let's make the change on R1: 

router eigrp 10
no auto-summary

Now let's take a look at R1's routing table - (Compare it to R1's routing table output above to see the difference):

R1: 
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 [90/307200] via 192.168.0.2, 00:00:07, FastEthernet0/0
C 10.45.100.0/24 is directly connected, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/0

As per the output above, R1 no longer believes that it has a summary route to the 10.0.0.0 /8 range of addresses and therefore has removed its route which was pointing to the Null0 interface. And, now that that's gone, R1 has now allowed itself to accept the summary route R2 is advertising, as highlighted in blue above.

Now let's take a look at R2's routing table to see what has changed there - (Compare it to R2's routing table output above to see the difference): 

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:06:58, Null0
C 10.16.0.0/24 is directly connected, FastEthernet0/1
D 10.45.100.0/24 [90/307200] via 192.168.0.1, 00:06:58, FastEthernet0/0
C 192.168.0.0/24 is directly connected, FastEthernet0/0

As per the first blue line, as you would expect, R2 still has its summary route in its routing table. However, if you take a look at the second blue line you will see that R2 now has a route to the 10.45.100.0 /24 network through R1 which it did not have before. Because of this, R2 now has a more specific route to the 10.45.100.0 /24 network than the one offered by the summary route. This means that instead of forwarding traffic destined for the 10.45.100.0 /24 network to Null0 as it did before, R2 will now forward it to 192.168.0.1, which is R1.

So, now that everyone is playing nicely, let's take a look at R4's routing table to see if it has changed: 

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 [90/332800] via 10.45.100.1, 00:40:02, FastEthernet0/1
C 10.45.100.0/24 is directly connected, FastEthernet0/1
D 192.168.0.0/24 [90/307200] via 10.45.100.1, 01:13:37, FastEthernet0/1

As per the blue line above, R4 has now installed the summary route advertised by R2, and, because R2 has a route to R3 this should mean that we are able to ping the whole way through - which is what we set out to do originally. Let's give it a try: 

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

As expected, our network is now running AOK.

In conclusion I would like to repeat that you should always use the "no auto-summary" command, and therefore always do your summarisiations manually. 

Update

Please see Part 2 for more information on the "auto-summary" command.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, May 15, 2010

EIGRP Route Advertising

In the forums that I frequently visit I always see people asking how EIGRP route advertising works. The users are not sure how to correctly use the network command and usually use more commands than are necessary. So in today's post, using the diagram below, I will explain how to advertise EIGRP routes properly.


Now before we get started let me explain what the network command actually does. The network command tells the router which directly connected routes (routes which the router owns/is a part of) it can advertise to its peers. In order for two routers to exchange EIGRP routes, they must both be part of the same subnet and have a network command specifying that particular subnet, or, at the very least, their specific IP address on that subnet. Confused? That's OK, I'll explain it in more detail soon.

Here is the topology we'll be using:


Let's take a look at what R1's routing table looks like:

10.0.0.0/32 is subnetted, 1 subnets
C 10.16.1.1 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0

As you can see, R1 only has routes to its directly connected networks. At this stage R1 has no idea that the 10.16.2.1 IP address on R2 even exists because R2 has no way of telling him. To rememdy this, lets enable EIGRP:

R1:
router eigrp 10
network 192.168.1.1 0.0.0.0
no auto-summary

R2:
router eigrp 10
network 192.168.1.2 0.0.0.0
no auto-summary

Note: Please see the no auto-summary blog entry for more information on what this command does.

The reason why we have used the 192.168.1.1 and 192.168.1.2 addresses with the network command is because, as per the above, EIGRP adjacencies can only be created between routers on the same subnet. By adding these commands, we have now started an EIGRP relationship, as the below log message tells us:

*Mar 1 00:32:02.935: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.1.2 (FastEthernet0/0) is up: new adjacency

OK so now that we've got an EIGRP adjacency, let's take another look R1's routing table:

10.0.0.0/32 is subnetted, 1 subnets
C 10.16.1.1 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0

As you can see, nothing has changed routing table wise. This is because we have not added network statements to the EIGRP configuration that allows the routers to advertise their other networks. Let's do that now:

R1:
router eigrp 10
network 10.16.1.1 0.0.0.0
no auto-summary

R2:
router eigrp 10
network 10.16.2.1 0.0.0.0
no auto-summary

Now that we have done that, let's take another look at R1's routing table:

10.0.0.0/32 is subnetted, 2 subnets
D 10.16.2.1 [90/409600] via 192.168.1.2, 00:00:04,FastEthernet0/0
C 10.16.1.1 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0

As per the blue line above R1 can now see R2's other network. This is because R2 told R1 about it through an EIGRP update.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Sunday, April 18, 2010

CBAC in Action, Part 2

In my previous CBAC post I covered how to deny all external traffic unless it is in response to a request someone on the LAN has made, e.g If you send a ping, CBAC will allow the ping reply traffic to come through the firewall.

However, this situation may not be ideal for everyone. What if you wanted to allow one or more protocols in to your network but still have the security that CBAC provides? For example, if you wanted a contractor to be able to SSH in to your network any time, day or night? I will show you how using the same topology as last time (except you will see that R3 has been renamed to SSH Source). Our goal is to allow R3 to SSH in to R2 without being blocked, while still blocking R4 (hacker) completely.

If you recall, our inbound ACL on R1 looks like this:

ip access-list extended DENY_IN

deny ip any any

So if we try to SSH in from R3 now, we should fail, which we do. See the output below:

R3#ssh -l cisco 192.168.0.2
% Destination unreachable; gateway or host down

However, if we add the following line to the ACL:

ip access-list extended DENY_IN
!!Allow SSH traffic in to the network if its source address is 10.10.10.2 and it is destined for 192.168.0.2
permit tcp host 10.10.10.2 host 192.168.0.2 eq 22
deny ip any any


We should now be able to SSH in to R2 from R3, which we can:

R3#ssh -l cisco 192.168.0.2

Password:

R2>

But just to make sure that all of our security measures are still enforced, lets try to ping from R3 to R2:

R3#ping 192.168.0.2

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

And let's also try to SSH in from R4 (hacker):

R4#ssh -l cisco 192.168.0.2
% Destination unreachable; gateway or host down

R4#

As you can see from the above two tests, even though R3's SSH traffic can get through to R2, its ping traffic cannot. And you can also see that R4's SSH traffic cannot get through at all. This is because the new ACL entry specifically says that only SSH traffic sourced from R3 and destined for R2 is allowed to enter the network.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

CBAC in Action, Part 1

In a previous post I talked about CBAC and a few of the ways in which it, in conjunction with NBAR can be used to secure your network. Today I will create a lab to show you how to put it to good use.

In this lab we have four routers, R1, R2, R3 and R4 (very original I know). Here are there designations:

  • R1 = Local LAN - Your network
  • R2 = Core - The core of your network and your internet connection
  • R3 = Ping Destination - A location you want to ping to
  • R4 = Hacker - A hacker that is trying to access your network


Now in order to protect the network we need to apply access lists and CBAC rules to the interfaces which are connected to untrusted networks. As per the diagram, this would be interface Fa0/0 and Fa1/0.

At present there are no security measures in place, so as per the example below, R3 (the ping destination) can successfully ping R2:

R3#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/57/100 ms
R3#

And, R4 (the hacker) can also ping R2:

R4#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 416/469/528 ms
R4#


And of course, R2 can ping both R3 and R4.

Now, to stop these external users (R3 and R4) from being able to communicate with R2, we will need to put inbound ACLs on R1's interfaces which connect to them - (Fa0/0 and Fa1/0). An ACL that denies all traffic will do the trick:

!!Create the ACL
ip access-list extended DENY_IN

deny ip any any
!
!!Apply it to the interface connected to R3
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group DENY_IN in
!
!!Apply it to the interface connected to R4
interface FastEthernet1/0
ip address 10.50.50.1 255.255.255.0
ip access-group DENY_IN in

As per the below output, R4 is now unable to ping to R2:

R4#ping 192.168.0.2

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

However, this also means that if R2 tries to ping R3 or R4, the ping will be unsuccessful because the returning traffic will be blocked by the incoming ACL:

R2#ping 10.10.10.2

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

This is obviously not ideal. To resolve this issue we need to create a CBAC rule which will watch our outgoing traffic and then create dynamic ACL entries at the top of our existing ACL to allow the return traffic to get back in to the network.

The following commands need to be entered on R1:

!!Create the CBAC rule to keep track of ICMP traffic
ip inspect name CBAC_OUT icmp
!
!!Apply it to the interface connected to R3
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group DENY_IN in
ip inspect CBAC_OUT out
!
!!Apply it to the interface connected to R4
interface FastEthernet1/0
ip address 10.50.50.1 255.255.255.0
ip access-group DENY_IN in
ip inspect CBAC_OUT out

As per above, R3 and R4 are still unable to ping to R2:

R4#ping 192.168.0.2

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

But we can now ping to them from R2:

R2#ping 10.50.50.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.50.50.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/121/192 ms
R2#

To view the temporary ACL entries that CBAC creates, perform a ping from R2 to R3 and then issue the "show ip inspect sessions" command on R1:

R1#show ip inspect sessions
Established Sessions
Session 664FD9A4 (192.168.0.2:8)=>(10.10.10.2:0) icmp SIS_OPEN

As you can see by the output of the above command, only ICMP traffic destined for the IP address that issued the ping command is allowed back in to the network, no other traffic. And, once the pings stop the temporary ACL entry is removed.

R1#sh ip inspect sessions

R1#

We have now successfully secured the network. External users are unable to send data to us unless we request that they do. In this example it was a ping reply but it can also be returning traffic from a HTTP server, FTP server, telnet session, SSH session, SIP call, etc.

For more information on CBAC or to see a more advanced CBAC configuration, please see my CBAC in Action, Part 2 post.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Get Involved - Fourms

Whether you are are a seasoned Cisco professional or just starting out, one of the best sources of information you will find (apart from this blog :P) are internet forums. You will be amazed at just how much you can learn from them, and, if you have the time, how much you can teach others too. It is also a great place to "network" (excuse the pun).

Forums that I frequently visit include:
  • Whirlpool Forum - An Australian forum that covers everything from VoIP to Network to PC Hardware.
  • Experts Exchange Forum -Like Whirlpool, "EE" covers a whole range of topics and has a reward system that encourages users to assist one another.
  • Cisco Forum - An excellent place to get assistance with your Cisco problems.
If you're having a problem and you just can't seem to resolve it, I can almost guarantee that someone on a forum will be able to help you (I speak from experience after having used the above mentioned forums). Everyone is so helpful and because most users are Cisco professionals there is nothing they have not seen before.

Forums also give you the confidence to try new things. For example, if you are interested in implementing a VoIP solution but you do not know the first thing about it, you can jump on to a forum and get the latest, most up-to-date information on prices, technologies and implementation methods with the push of a couple of buttons. They also gives you a sense of re-assurance because you know that if you don't understand something or if you get stuck, there are users on line who are ready to help 24 hours a day, 7 days a week.

You will find that some forums (including the ones mentioned above) not only allow you "chat forums", they also have other resources including Knowledge Bases or Frequently Asked Question pages which in themselves are a great source of information.

Once you do get your problems resolved it is always a good idea to stick around and assist others who are having trouble with their networks too. It is a great feeling when you know you've helped someone fix their problems and it is a great way to keep your knowledge fresh instead of letting it fade away in the back of your mind.
So if you are not part of a forum I strongly suggest you sign up today. You won't regret it!

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, April 17, 2010

CBAC Firewall

In my last post I mentioned the Cisco IOS firewall feature known as CBAC (Context-Based Access Control). Today I will describe it in more detail and explain how you can use it to increase the security of your network.

As you may know, a firewall is used to protect your network from the outside world and all of the nasty hackers out there. With each passing day hackers' intrusion techniques are become more advanced and highly complex, and unfortunately basic ACLs are simply not good enough to protect you anymore. Thankfully CBAC (more commonly known to the wider I.T community as Stateful Packet Inspection, (SPI)) has come to the rescue.

CBAC, with the help of NBAR, reads the packets coming in to and going out of your network and creates dynamic ACL entries that will either permit or deny these traffic flows.

For example, if you want to allow ICMP and HTTP traffic (pings and internet browsing) out of your network, you would have to create an "outbound" access list on your internet facing interface. Then, to allow the returning traffic to re enter your network you would have to create an "inbound" access list, however, this is where your potential troubles start. This is because unless your "inbound" access list specifies all of the IP addresses that you intend to ping to or surf to, you are going to have to allow all ICMP and HTTP traffic in to your network, regardless of the source,which is not very secure.

Fortunately, as mentioned above CBAC has come to the rescue. With its dynamic ACL creations all you have to do is create the "outbound" access list which specifies what your users can and cannot do and CBAC does the rest. This is because CBAC watches the traffic that leaves your network and then creates a dynamic ACL to allow the returning traffic (and only the returning traffic) back in to the network.

See my CBAC in Action and CBAC in Action, Part 2 posts to see a real life example of how you can configure CBAC in your network.
As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Friday, April 16, 2010

NBAR and its Many Uses

Overview 

NBAR, also known as Network Based Application Recognition is an invaluable tool that many people do not know exists or simply just don't use it enough. 

As the name suggests, NBAR reads packets that flow through a router and "recognises" the types of applications that are sending the packets. Examples of applications that can be recognised include:

  • FTP
  • Kazaa
  • HTTP URL Addresses
  • Bit Torrent
  • Many, many more!
And the good news is that this handy little feature can be put to use in many different ways, some of which I have discussed below.  

NBAR & Access Control 

Before NBAR came along, one of the techniques Network Administrators woulduse to stop users from getting up to mischief was blocking "bad" ports. However, with a little bit of know how it is very easy to change ports thereby making the "bad" traffic look like legitimate traffic. By using NBAR you don't need to specify port numbers, you just specify the application that you would like to block, apply it to an interface and you're done. Because NBAR reads the packets (up to, and including Layer 7 information), it is still able to block the traffic even if the users change their port numbers.

Note: NBAR can be used in conjunction with Context-Based Access Control (CBAC) to create an extremely effective firewall on a Cisco router. 

NBAR & URL Filtering

NBAR can also be used to block URLs. This can be a great little feature if you have a small office setup and do not have the time or the resources to set up a proxy server.

The filtering also allows you to use wildcard masks so blocking websites with multiple sub-domains (such as YouTube) can be done just as easily as blocking a single domain. 

NBAR & QoS

Another application for NBAR is with QoS policies. Rather than specifying port numbers for different traffic types, NBAR will automatically identify the port numbers for you. This is a small gain I know, but it makes life a little easier. It also makes your config somewhat more readable in that instead of creating a class-map and ACL that specifies TCP port 80 and 23, you can use NBAR to match "HTTP" traffic and "Telnet" instead.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Wednesday, April 14, 2010

GNS3 + Real Cisco Gear

For those of you who have never heard of GNS3 before, you are in for a treat!

What it does is allow you to run multiple routers on your computer in a virtualised environment, and, because it uses real Cisco IOSes you are not limited to a short group of commands as you are when using simulators, you actually have access to the entire command tree as if the IOS was put on a real router.

At risk of stating the obvious, this is a huge asset for anyone who is interested in networking. Whether you are a network engineer, studying for a certification or just an enthusiast, this application is perfect for you.


Another big advantage is the amount of money it can save you. Rather than spend a couple of hundred dollars on a router, using GNS3 you can simply whip up one, two, ten or more in an instant! Imagine the complex topologies you could create with that!

Now I know you must be thinking "this is too good to be true", and, when something is too good to be true it usually is, so I will let you in on one (very small) piece of bad news. GNS3 is unable to emulate switches. That is because switches do most of their work in hardware ASICs whereas the routers that GNS3 emulates do most of their work in software. Speaking of which, this leads me to my next (very small) bit of bad news. GNS3 is not able to support every single router released, however, to its defence, it does support a large number of them. For information on both of these downfalls, see the FAQ page.

Now, back to the positives. Although GNS3 cannot emulate switches, some of the routers it supports do support ethernet modules, so if you really want to test your Layer 2 skills in GNS3 you could always set up a few routers with switching modules and away you go.

And for those of you out there with existing labs, this post relates to you too! Why you ask? Because you can connect your physical equipment to your virtual lab. As you will see in my future posts, you are able to create a complex Layer 3 network in the virtual network and then connect it to your real router, switch or multi layer switch, then connect PCs to your switches so they become part of the network too. Amazing!!

So, if you haven't seen or used GNS3 yet I suggest you download it and give it a go, you won't be disappointed.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Tuesday, April 13, 2010

Welcome!

Hello and welcome to my blog.

I know what you are thinking, "not another Cisco Blog!", but this one will be different, I promise :)

The point of this blog is to patch up the holes that other blogs/websites leave in the information that they provide. While researching topics in the past, I have found on more than a few occasions that some sites fail to fully explain what it is they are talking about (whether it be a protocol, QoS, troubleshooting, etc) and by the end of it I am left scratching my head and feeling like I know less than I did before I found the site.

So with this in mind I am going to explain each topic I discuss in great detail to ensure that this sort of thing does not happen to my readers. Having said that though, I do not plan to re-invent the wheel. If there is a great resource out there that will assist me in explaining a topic, I will gladly link to it and perhaps expand on it if need be.

In addition to writing, I will also use real labs to further help me explain the subjects that I cover, and I will also include screenshots, packet captures and running-configs to further explain how the whole thing came together.

Anyway, that's all for now folks! Stay tuned and I hope you enjoy your stay!!

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.