Networking Search

Sunday, July 19, 2009

Five ways to secure your Cisco routers and switches

Fundamentals:
Five ways to secure your Cisco routers and switches

Author: David Davis
(april 2008)


Recently, Cisco Subnet blogger Brad Reese wrote the article, “Expert warns of scam to blackmail companies for cash to get back access to their Cisco routers.” In that post, he wrote about hackers who manage to hijack a company’s routers and then extort money from them by threatening to take down the network. The hackers were able to obtain control of the network because of poorly written Cisco IOS ACLs, easily guessed passwords, and unencrypted SNMP community strings (or easily guessed community strings).

Don’t let this happen to you and your network. Here are my top five best practices to secure your routers, your network, and your company from malicious attacks.

1. Understand the basics of router security

You must understand the basics of router security. Here are the essentials:

Physically secure the routers
If your routers are not physically secured, anyone can walk up, perform a password reset, and gain full access to that router’s configuration. Even if this isn’t a core router, they could take down your network by poisoning the routing tables on all routers. For this reason, routers should be in a locked room and preferably have video surveillance. Additionally, reliable electrical power and cooling must be provided.

Lock down the router with passwords
Routers must be secured with passwords at both the login mode (to prevent initial access) and the privileged mode (to prevent configuration changes). For more information on these different levels in the Cisco IOS, please see my article, “Understand the levels of privilege in the Cisco IOS.”

Apply login mode passwords on Console, AUX, and VTY (telnet/ssh) interfaces
Password controlled access needs not only to be on the VTY lines to prevent network access, but also on the Console and AUX ports. If the Console port is locked but the AUX port doesn’t have a password, then locking the Console wasn’t of much use, was it?

Set the correct time and date
To ensure that logs are correct and have not been tampered with, you must ensure that the router has the correct time and date. For more information, please see “Synchronize a Cisco router’s clock with Network Time Protocol (NTP).”

Enable proper logging
Logging should be enabled, preferably, back to a central source like a syslog server. At minimum, you need to configure a buffered log on the router. However, if the power is lost to that router, that local buffered log is lost. For this reason, to really be secure, you need to configure a syslog server (see the article, “SolutionBase: Monitor your network with Kiwi Syslog“), and send all router logs to that server. You could also put in the open source or commercial version of Tripwire. Preferably, you should increase the level of logging and even log configuration changes to the router. For example, you can use the following command to enable SNMP traps for configuration changes:

snmp-server enable traps config

For more information on Cisco router logging, please see, “Get to know your logging options in the Cisco IOS.”

Back up router configurations to a central source
Let’s say that someone does take control of your router or wipes out your router configurations. To replace that router quickly or replace the configuration, you need to have a backup of that configuration. To do this, ensure that your routers are backed up whenever configuration changes are made or each week or day. I have enjoyed using Kiwi CatTools to do this. For more information, see “Automate changes to your Cisco router with Kiwi CatTools.”

Secure other network devices such as switches and wireless access
Most of the items listed here also apply to Cisco switches and wireless access points. Here are a couple of articles on those topics that you should check out:

* 10 things you should know about securing wireless connections
* Lock Down Switch Port Security

Two more areas that I consider to be at the basic level of router security are locking down network access to the router with a stateful firewall or ACL and encrypting sensitive network traffic, but I will cover these points in more detail below (sections three and five, respectively).


2. Know your network: Diagram, audit, and document

If you are responsible for the security of a network you should know that network like you know the vulnerable doors and windows (think entry points) of your house.

You should diagram your network so that you have a map to help you and others visualize the entire network.

You should have the router configurations backed up (see Kiwi CatTools above). Finally, you should periodically audit your network security, both internally and externally (via a third party). There are tons of network scanning and auditing tools available. Here is a recent article of mine that covered one of them: “Audit your Cisco router’s security with Nipper.”

3. Protect your router with a firewall and ACLs

In Reese’s post about the hackers, he mentioned the fact that the company had poor access control lists (ACLs) in place on their routers. ACLs are typically what protect routers from attack. However, due to their complexity, many of them end up being misconfigured or ineffective. Make sure that your ACLs allow only traffic to the router and through the router that should be there. For internal routers this will only be internal traffic.

Make sure you understand that whatever isn’t permitted will be denied (the implicit deny), that ACLs are processed from the top down, that there should never be a permit any in the ACL, and that the ACL must be applied to an interface in the proper direction to be enabled. For more information on ACLs, please see some of my articles and video on this topic:

* Secure your router with Cisco’s SDM Firewall Policy Wizard
* Cisco IOS access lists: 10 things you should know
* Use advanced parameters on your Cisco IOS ACLs
* VIDEO: Harden your Cisco Router with IOS ACLs

Keep in mind that ACLs aren’t just used to prevent traffic from going through the router. They are also used to control SSH traffic, routing update, and to throttle traffic. For more information, see:

* Learn additional uses for Cisco IOS access control lists
* Control unwanted traffic on your Cisco router with CAR

Besides ACLs, the Cisco IOS offers a real stateful firewall if you use the Security/Firewall version of the IOS. A stateful firewall will be much better than just using ACLs. I recommend checking out my article, “Protect your network with the Cisco IOS Firewall,” and consider implementing one on your routers.

4. Change your passwords and make them complex

Another method that hackers use to take control of networks is password guessing or password sniffing. To prevent this, you should CHANGE YOUR PASSWORDS TO COMPLEX PASSWORDS TODAY. Don’t wait another day! An example of a complex password is MySuper!S3cr3tPa$.

Make sure you always use type 5 password encryption on your routers (see “Be aware of how easily someone can crack a Cisco IOS password“).

Make sure this command is on your router to encrypt most (but not all) passwords with type 5 encryption:

service password-encryption

Also, keep in mind that we aren’t just talking about login passwords. This includes all SNMP community strings and routing protocol update passwords. All of those should be complex and changed periodically.

For more information on this topic, please see, “How to Configure Passwords to Secure your Cisco Router.”

5. Always encrypt sensitive network traffic

Finally, hackers can obtain passwords to your routers by sniffing network traffic when you log in to your router with telnet, perform a “show run” via telnet, or use unencrypted SNMP strings.

You should always encrypt sensitive network traffic by using SSH and SNMP encryption. Start by enabling SSH and disable telnet to all network devices that support it (see “Configure SSH on your Cisco Router“).

If you are using SNMP, enable SNMP v3 with encryption and use it exclusively (for more information, see AES and 3-DES Encryption Support for SNMP Version 3).

Be careful

The point of this article is to (1) encourage you to take action to secure your network before malicious attackers take control of it and (2) to show you exactly which actions you need to take.

You shouldn’t assume that your network isn’t a target because your company isn’t high profile or your data wouldn’t be valuable to an attacker. Take every reasonable step to protect your network; as you can see from this post, these steps aren’t necessarily difficult or costly.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.

souce : www.techrepublic.com

Thursday, June 11, 2009

What you need to know about Cisco IOS access-list filtering

What you need to know about Cisco IOS access-list filtering

Let’s face it, if you don’t use Cisco IOS access lists (ACL) every day, they can be very painful to use. Why are ACLs so painful? Besides just being difficult to use, the penalty for mistake is huge. In one swift swoop, you could incorrectly permit malicious attackers onto your network or incorrectly deny all valid users from your network. Either way, the consequences could be devastating to your company and to your career. So how do you prevent this from happening? If you follow these guidelines, you will be “feeling good again” about your Cisco ACLs.

Know what an ACL can and cannot do

In the simplest of terms, a Cisco IOS ACL is used to define traffic. Once that traffic is defined, some action can then be taken on that traffic.

Commonly, an ACL is associated with the filtering of IP packets (Network Layer 3 of the OSI Model) as they pass through a router. In other words, it is used to permit or deny traffic through a router. However, if you just define the ACL only and don’t apply it to an interface using the access-group command, nothing happens.

While ACLs can be used for many functions like QoS, route filtering, and allowing access to the router, in this article, we will focus on using ACLs for filtering traffic in and out of the router.

Know the syntax of ACLs

To configure an ACL you need to include some basic information about which packets to permit or deny.

The general syntax for a standard access list is:

access-list {list number} permit | deny | [source address} [source mask]

Note that the standard ACL can only permit or deny traffic based on the source of the traffic.

The general syntax of a TCP extended access list is:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name] [fragments]

You should also know that extended ACL can filter IP traffic, TCP, UDP, ICMP, and other types of traffic. The syntax above is to filter TCP traffic.

Know that ACLs use wildcard masks

Cisco IOS ACLs use wildcard masks. These wildcard masks are required anytime you enter an IP address in your ACL. The only way NOT to enter an IP address (thus, using a wildcard mask) is to enter a keyword like “any” or use the keyword “host” before the absolute IP address of a host on the network.

Wildcard masks are the binary reverse of a subnet mask. Thus, to calculate a wildcard mask, you take the subnet mask of a network address or IP address, convert it to binary, turn all the 1s into 0s and the 0s into 1s, and convert it back to decimal. Sounds complicated, but it really isn’t. If the subnet mask is masked at the 8-bit subnet boundaries, then a 0 will turn into a 255 and a 255 will turn into a 0. Here are a few examples:

  • SN 255.0.0.0 = wildcard 0.255.255.255
  • SN 255.255.255.0 = wildcard 0.0.0.255
  • SN 255.255.128.0 = wildcard 0.0.127.255
  • SN 255.255.255.224 = 0.0.0.31

Do NOT use a subnet mask in a wildcard mask on a Cisco IOS router or switch, or you will end up with unintended results. (On the other hand, if you are configuring an ACL on a Cisco PIX, use regular subnet masks, not wildcard masks).

Know how to create an ACL and apply it to an interface

For example, here’s how a sample configuration might look for access list 1:

Router(config)# access-list 1 permit 172.16.30.0 0.0.0.255
Router(config-if)# interface e0/0
Router(config-if)# ip access-group 1 out

The ip access-group command is used to apply an ACL to an interface and specify the direction that it applies.

The commands above permit any traffic coming from IP network 172.16.30.0 going OUT the router’s Ethernet 0/0 interface.

Know the implicit deny

Let me ask you this: What is allowed through the ACL above? Answer: Only the traffic from the 172.16.30.0 /24 network. Why is that? That is because at the end of every ACL, whether you see it or not, ALL TRAFFIC IS IMPLICITLY DENIED.

So, what traffic is allowed through the ACL below?

Router(config)# access-list 1 deny 172.16.30.0 0.0.0.255

That’s right - NO TRAFFIC is allowed because certain traffic is explicitly denied and ALL OTHER TRAFFIC IS DENIED by the implicit deny.

How do you see the traffic being denied? You can enter your own explicit deny with the log keyword, like this:

Router(config)# access-list 1 permit 172.16.30.0 0.0.0.255
Router(config)# access-list 1 deny any log

Know that ACLs use top-down processing

Cisco IOS ACLs use top-down processing. This means that when a condition in the ACL is met, all processing is stopped. Thus, if there is a permit for network 1.1.1.0 in the fifth line of the ACL but it is denied in the third line of the ACL, then that traffic is denied.

Know the three Ps of ACLs

Remember, you can only apply ONE ACL:

  • Per Interface
  • Per Protocol
  • Per Direction

As most of us are applying IP ACLs, the protocol doesn’t matter that much, but the important thing to know is that you can apply only ONE ACL on each interface in each direction. In other words, you can apply only one INBOUND and one OUTBOUND ACL per interface.

Know how to verify which ACLs are applied and which are configured

Showing what ACLs are created and what ACLs are applied is easy if you know just a few commands. These commands are:

  • show access-lists
  • show ip interface
  • show running-config

Know that there are many methods and types of ACLs

The Cisco IOS supports IP Standard and Extended ACLs in both named and numbered versions. Additionally, there are reflexive, dynamic, and lock-and-key access lists, among many others.

Know how ACLs can be used in the real world

While you may understand the concept of ACLs and how to configure them, it is important to know how to use them in the real world.

Here are a few business applications for ACLs:

1. Basic packet filtering for security: Filter traffic from a host, a network, a protocol, or port.

2. Packet filtering for bandwidth control: Say that a streaming audio or video application was using network bandwidth, and it was on a certain port number. With an ACL, you could discard those video and audio packets to prevent overutilization of bandwidth.

3. Other functions with ACLs: Route filtering, QoS, controlling access to the router, etc.

Know where to find more resources to learn ACLs

There is a lot to know about ACLs, and we can’t cover it all in this short format. To learn more about ACLs, here are some links to other articles and videos I have created on this topic.

  • TechRepublic.com: Use Advanced Parameters on Your Cisco IOS ACLs
  • TechRepublic.com: Cisco IOS Access Lists - 10 Things You Should Know
  • HappyRouter.com: Free Video - Hardening Your Router with Cisco IOS ACLs
  • Petri.co.il: How to Edit Cisco IOS ACLs Using Line Numbers

Conclusion

ACLs are the least understood feature that new Cisco administrators and CCNA candidates struggle with. I hope you find this information about Cisco IOS access lists helpful, and you keep it handy to “cure those ACL pains” whenever they come up.


David DavisDavid Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users. Read his full bio and profile.


article source : techrepublic.com

Monday, September 15, 2008

Cisco IP Accounting

IP Accounting is a very useful accounting feature in Cisco IOS, but it’s not as well known as other features, such as NetFlow. The fact that Cisco has considered replacing IP Accounting by adding new features to NetFlow potentially turns IP Accounting into a corner case solution.

However, compared to NetFlow, IP Accounting offers some advantages that make it an interesting feature to investigate: easy results retrieval via a MIB and limited resource consumption. Furthermore, access-list accounting currently cannot be solved with the NetFlow implementation. Note that NetFlow recently added the export of the MAC address as a new information element

link-link networking

  • http://www.net-sense.com/flash_report.htm

    Situs memanage cisco device dengan lebih cepat

Wednesday, July 9, 2008

Troubleshoot Cisco routers and switches using the debug commands

Troubleshoot cisco routers and switches using the debug commands
by = David Davis


Often, you cannot solve router and switch issues with “show” commands alone. At some point, you will have to use Debug commands to find out what is really going on behind the scenes. In this article, you will learn about Cisco IOS Debug commands and how they can help you.
What makes Cisco IOS Debug commands so useful?

Cisco IOS Show commands can tell you many things about what is going on with your router or switch, but they can’t tell you everything. For example, Show commands cannot tell you when routes drop in or out of the routing table, why an ISDN line failed to connect, whether a packet really went out the router, or what ICMP error code was received. On the other hand, Cisco IOS Debug commands can tell you all these things, and more.

Besides providing more detailed information than what Show commands can provide, Debug commands have the benefit of providing information in “real time” (or dynamically). This is contrary to Show commands that just take a snapshot in time and display the results on your console (somewhat static results). This real-time difference can be very helpful in diagnosing problems.


How do I use Debug commands?

Let’s take a look at a simple example. We are going to view RIP (Routing Information Protocol) in Debug mode.

Router# debug ip RIP

RIP protocol debugging is on

To verify what debugging is enabled, use this command:

Router# show debug

RIP protocol debugging is on

The output from whatever type of debug is enabled will be sent to wherever the Cisco IOS logging system tells that output to go. Either you will receive the output on your screen, it will go to the buffered log on the router, or it will go to a syslog server across the network (or all of these).

To see what level the various outputs are set to and where the output will go, type:

Router# show logging

Syslog logging: enabled (1 messages dropped, 3 messages rate-limited,

0 flushes, 0 overruns, xml disabled, filtering disabled)

Console logging: level debugging, 8 messages logged, xml disabled,

filtering disabled

Monitor logging: level debugging, 0 messages logged, xml disabled,

filtering disabled

Buffer logging: level warnings, 2 messages logged, xml disabled,

filtering disabled

Logging Exception size (4096 bytes)

Count and timestamp logging messages: disabled

Trap logging: level informational, 12 message lines logged

Log Buffer (51200 bytes):

*Jun 9 20:56:49.195: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Jun 9 20:56:49.231: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

Router#

The console should display RIP updates that are sent and received through the RIP protocol. Here is an example of what you might see for RIP debugging:

*Jun 9 21:13:56.471: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)

*Jun 9 21:13:56.471: RIP: build update entries - suppressing null update

*Jun 9 21:14:22.519: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (1.1.1.1)

*Jun 9 21:14:22.519: RIP: build update entries - suppressing null update

Remember that you should use Debug only for a short time to get a snippet of information, and then turn Debug off as it can be a serious performance hit on your router.

There are several commands for turning off Debug. You could type undebug all or a precreated alias, un all (for more information on aliases, see my article “Enter Commands More Efficiently with Cisco Command Aliases“), but the no debug command works fine also.

Router# no debug

If you type debug ?, you will see that there are over 200+ Debug commands, and each of those has many options. Debugging RIP is just a very simple example.

What are the three most common mistakes made when using Debug?

Using Debug can be a risky proposition, and even experienced admins have made mistakes when using it.

  • I’d say the number one common mistake is to forget that you have left Debug on in a production environment. Sometimes, we get so focused on resolving the issue that when we get it resolved, we are on to the next “opportunity” and forget to issue the no debug command to turn off debugging. I think that many a network admin can attest to horror stories of when they brought their router to its knees because they forgot this simple task of turning off Debug.

  • The second common mistake would be not realizing the effect on your router of issuing a lot of Debug commands at the same time. Remember that the router’s job is to forward packets, not to monitor processes and generate Debug messages. For example, you are having a problem with the packets on your router, so you issue the Debug statement debug ip packet. Then you decide that you want to view the events on the RIP protocol. Now, you have two separate Debug statements that are being processed and sent to the console. Debug statements are processed at a higher priority than other network traffic, so, needless to say, these Debug statements can jeopardize your router’s performance.

  • The third common mistake made with the Debug command is entering debug all or debug ip packet detail on a production router. Either one of these commands can crash a heavily loaded production router. Luckily, there is an “are you sure” prompt before these take effect; however, that hasn’t prevented every debug-related catastrophe. You should be as specific as possible when using Debug, and then turn it off as quickly as possible. Also, always test your Debug commands on a test router before using them in a production environment.

What are some common scenarios when using Debug to troubleshoot?

To learn about the top 10 most useful Cisco IOS Debug commands, please read my TechRepublic article “Get IT Done: 10 Ways to Mitigate Problems Using Cisco IOS Debug.”

In conclusion

The Cisco IOS Debug commands are very powerful commands that every Cisco admin should know how to use properly. With Cisco IOS Debug commands, you can get down to the details of whatever protocol or feature you are troubleshooting in order to resolve your problem.

For more information on Cisco IOS Debug commands, see the Cisco IOS Debug Command Reference.

David Davis has worked in the IT industry for twelve years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.


Article Sources = www.techrepublic.com

Cisco Administration 101 - Understand the OSI Model to become a better cisco Troubleshooter

Cisco Administration 101: Understand the OSI model to become a better Cisco troubleshooter.

By = David Davis


What is the OSI model?


The OSI model is a hierarchical model of how different devices, protocols, and applications can interoperate to provide a network. The OSI (open systems interconnect) model was created by the International Standards Organization (ISO).

The applications and protocols that make up the network reside at different layers of the OSI model. Those layers are:

  • Layer 7 – Application
  • Layer 6 – Presentation
  • Layer 5 – Session
  • Layer 4 – Transport
  • Layer 3 – Network
  • Layer 2 – Data Link
  • Layer 1 – Physical

For certification tests like the Cisco CCNA certification, most admins remember these layers by taking the first letter of the layer and matching it with a word. Here are some common ways to remember the OSI model:

  • All People Seem To Need Data Processing
  • Please Do Not Throw Sausage Pizza Away
  • Phew Dead Ninja Turtles Smell Particularly Awful

A common question is, “What application or protocol resides at each of the layers?” Here is a general overview:

  • Layer 7 - Application

    The application layer is where the protocols and services that make up your application reside. Examples of what is located here are: Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).
  • Layer 6 - Presentation

    The presentation layer “presents” the session layer data to the application. Examples of what is located here are: encryption (like IPSec), ASCII, and JPG.
  • Layer 5 - Session

    This layer is responsible for initiating and terminating network connections. Examples of the session layer are Remote Procedure Call (RPC) functions and the login portion of a SQL session.
  • Layer 4 - Transport

    TCP and UDP work at the transport layer. TCP provides the reliable, in-order delivery of your data, as well as error correction, sequencing, and windowing (flow control). Additionally, TCP at the transport layer provides source and destination port numbers that are commonly associated with applications. For example, TCP port 25 is SMTP, 23 is telnet, 22 is SSH, 80 is HTTP, and so on. These port numbers are very important if you are configuring an ACL (see my article, “
    What you need to know about Cisco IOS access-list filtering“) or studying for a certification test like the CCNA. Data at the transport layer is called a segment.
  • Layer 3 - Network

    The network layer is where the “IP” part of “TCP/IP” happens. IP is responsible for addressing in the network. Because IP works at layer 3, you could also say that routing and routers work at layer 3. Any data at layer 3 is called a packet.
  • Layer 2 - Data Link

    If you think about a WAN, there are many protocols that work at layer 2 (like PPP and Frame-Relay).
    However, if you just look at the LAN, the most well-known protocol associated with layer 2 is Ethernet. The Ethernet protocol uses MAC addresses to identify unique devices on the network. Any data at layer 2 is called a frame. Ethernet switches work at layer 2 to switch Ethernet packets. To do this, they keep a MAC address table or CAM table — mapping MAC addresses to switch ports.
  • Layer 1 - Physical

    The physical layer provides the actual connection between devices. Ethernet cables and fiber optic cables work at layer 1. Data goes through the cables via electricity or light. That data is now represented as a bit (a one or a zero).

How does the OSI model help you on a practical basis?

While most of us know the OSI model, I believe that most of us do not make the very helpful connection between the OSI model and the daily, real-world tasks and troubleshooting that a Cisco admin must perform.

Most of us think of the OSI model as some kind of arcane textbook concept that must be learned for the exam and can then be forgotten. On the contrary, I believe it can be extremely helpful to Cisco admins on a day-to-day basis. Here are four ways the OSI model can help you, as a Cisco admin:

Understanding the network “big picture”

There are many new Cisco admins out there who may understand how to unlock a switch port or how to configure IP addressing, but they don’t see, really, how the network functions. By understanding the OSI model, you can see the “big picture” of how the network really works.

You can understand how bits are sent as electrical signals across copper wires; how those are reassembled into frames by Ethernet in layer 2; how the frames are switched to the right destination; how that PC disassembles the frame and packet to verify that it is the right destination IP; how it breaks up the segment at the transport layer, responds with an acknowledgement (ACK), and sends the data up to the session, presentation, and application layers; and how every tiny communication requires this whole process to happen many times per second.

Configure ACLs for traffic filtering and QoS

By understanding the OSI model you will better be able to configure Cisco IOS ACLs. Those ACLs can them be used to filter traffic or provide for router services on that traffic -– like QoS. By knowing that the transport layer is where TCP is and that port numbers are used to identify applications, you will understand more clearly how to create ACLs that define that traffic. You will also create better ACLs when you keep in mind the different protocols that could be in use at the transport layer. For example, you might want an ACL that defines UDP or ICMP (ICMP actually functions at layer 3, network).

Once you create the proper ACL, you can then take action on that traffic by filtering it or providing QoS for it. (See my articles “Cisco IOS access lists: 10 things you should know” and “What you need to know about Cisco IOS access-list filtering.”)

What is also interesting is that BGP works at layer 4 (transport) because it uses TCP; however, OSPF, IGMP, and ICMP all work at layer 3 (network). Also, ARP works between layers 2 and 3 as it maps MAC addresses to IP addresses.

Prepare for certification

Certainly, any entry-level certification will require you to learn about the OSI model and answer some questions about it. For example, the CCENT/CCNA and Network+ certifications all require that you understand the OSI model. I believe that this all comes back again to “knowing the big picture.”

Troubleshooting the network

Once you understand the OSI model, you will be a much better network troubleshooter. For example, in my article “Choosing a network troubleshooting methodology,” I cover how to use the OSI model to troubleshoot the network either by starting at the top or the bottom or by using the “divide and conquer” approach.

  • If your Ethernet cable is disconnected, at what layer is your problem to be found? Answer: layer 1.
  • If your ACL is dropping your TCP data, where is the trouble? Answer: layer 4.
  • If your IPSec is misconfigured, where is the problem? Answer: layer 4.

Learn more

By understanding the OSI model, you will be able to do a lot more than pass your certification test. The OSI model may have been designed to help vendors ensure that their network products interoperate with others, but it is here to help Cisco admins, like us, visualize how the network works and troubleshoot it when it doesn’t.

For more information on the OSI model, see Cisco’s Internetworking Technology Handbook.

David Davis has worked in the IT industry for twelve years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

Article Source = www.techrepublic