I've been planning to retake my Cisco Certified Network Associate exam for a few months. The exam I passed before retires this September, so to keep the review to a minimum I'm working to get it done before then.
I've put it off long enough and the test is scheduled.
Now I'm studying like crazy to be ready, so the truck gets put on hold. Music gets put on hold. Everything gets put on hold. Every time this happens I resolve to be more dilligent in my skills maintenance, and every time I wait until I have to panic to get anything accomplished. This appears to be a character flaw.
At any rate, check out my facebook page for announcements of upcoming gigs, who I'm playing with and where to find me next. The next performance will be in Becker with Green Light Night, August 16th. I believe this is a private party, but if you get in touch with me I'm sure I can arrange a guest list for your attendance. Maybe some of my Twin Cities friends would like to make the shorter trip?
More thoughts as they come, otherwise check out my networking blog for the only thing I'm currently thinking about...
Showing posts with label CCNA. Show all posts
Showing posts with label CCNA. Show all posts
Wednesday, August 7, 2013
Tuesday, July 23, 2013
Back at the geek stuff
Well, I keep intending to post information about life and thoughts about it and all the other musings I typically generate that I think someone should hear. I assure you, I have more thoughts than have made it to this blog for quite some time.
Anyhow, the majority of my blogging has been at my "Greg and the Network" blog lately as I prepare to retake my CCNA. I'm reviewing all my CCNA material and brushing up on the finer points of all sorts of geeky stuff for those who are interested.
Other than that, we're alive and well. Having just passed 13 years of wedded bliss, we are busy enjoying summer and all that goes with it. I expect to blog more soon, since summer in Minnesota really only lasts a few weeks anyhow.
Also wanted to make sure you all know that "Green Light Night" is performing on September 21 at O'Brien's Pub in Rice, MN. I hope to see everyone there.
Anyhow, the majority of my blogging has been at my "Greg and the Network" blog lately as I prepare to retake my CCNA. I'm reviewing all my CCNA material and brushing up on the finer points of all sorts of geeky stuff for those who are interested.
Other than that, we're alive and well. Having just passed 13 years of wedded bliss, we are busy enjoying summer and all that goes with it. I expect to blog more soon, since summer in Minnesota really only lasts a few weeks anyhow.
Also wanted to make sure you all know that "Green Light Night" is performing on September 21 at O'Brien's Pub in Rice, MN. I hope to see everyone there.
Thursday, July 2, 2009
Tuesday, June 16, 2009
Spanning-tree
Spanning-tree protocol is described by the IEEE 802.1d protocol. (I've never, in a real-world situation needed to know that, but it seems like the sort of thing Cisco would put on their test to see if you were paying attention). It is a layer 2 protocol that prevents loops in traffic by figuring out what is the fastest path to the root bridge (or root switch).
STP bases all its calculation on cost, which it figures by default by the speed of the link. STP costs are assigned as follows:
10 Gb - Cost 2
1 GB - Cost 4
100 Mb - Cost 19
10 Mb - Cost 100
When a switch comes online, it sends out a Bridge Protocol Data Unit (BPDU) that carries its bridge ID, which is a combination of the switches priority (32768 by default, but configurable in multiples of 4096) combined with the MAC address of the switch. Lowest Bridge ID becomes the root bridge. It then sends out BPDU's every 2 seconds, and as long as it doesn't receive a response that another switch on the network has a lower ID, it will continue happily as the root bridge.
Once the root bridge is elected, it defines root ports and designated ports throughout the network. Root ports are simply the ports that have the lowest cost back to the root, and designated ports are the ports that connect to other switches. The cost is calculated by adding all cost values for the entire path back to the root. So if you have 3 switches, and there is a 1Gb link between switch A and switch B, and a 100 Mb link between switch B and switch C, the cost for the path is 23 (4 + 19).
If there are multiple paths to the root, the switch will use the following means of deciding which port will forward and which will block. It looks first at cost, with the lowest cost going into a forwarding state and the higher cost blocking. If there are multiple paths with the same cost, the switch will look at bridge ID, with the lowest going to forwarding state. If there are identical bridge ID's it will look at port priority, which is an arbitrarily assigned number that defaults to 128 but can be configured to choose one path over another. If there continues to be a tie, the switch will then look at port number, with the lowest interface ID going to forward packets.
Spanning-tree ports go through transitions, where each port ends either in a forwarding or blocking state. There are timers assigned to each state, and each state has a different function. They are:
Disabled - the port is obviously not forwarding
Blocking - the portaccepts BPDu's but does not send other user data
Listening - port is accepting traffic and accerpts and sends BPDU's
Learning - port is accepting traffic and entering MAC addresses into memory
Forwarding - the port is forwarding user data as well as BPDU's
To transition from blocking to listening takes 20 seconds, from listening to learning takes 15 seconds and from learning to forwarding takes another 15 seconds. When there is a topology change, STP will take 50 seconds to transition and resume network connectivity. PVSTP+ can converge in 2 seconds, but that is another topic... These timers are dictated by the root bridge, so to modify them in your network you only need to change them on the root and they will propagate throughout the network via BPDU's.
Later, VLAN's.
STP bases all its calculation on cost, which it figures by default by the speed of the link. STP costs are assigned as follows:
10 Gb - Cost 2
1 GB - Cost 4
100 Mb - Cost 19
10 Mb - Cost 100
When a switch comes online, it sends out a Bridge Protocol Data Unit (BPDU) that carries its bridge ID, which is a combination of the switches priority (32768 by default, but configurable in multiples of 4096) combined with the MAC address of the switch. Lowest Bridge ID becomes the root bridge. It then sends out BPDU's every 2 seconds, and as long as it doesn't receive a response that another switch on the network has a lower ID, it will continue happily as the root bridge.
Once the root bridge is elected, it defines root ports and designated ports throughout the network. Root ports are simply the ports that have the lowest cost back to the root, and designated ports are the ports that connect to other switches. The cost is calculated by adding all cost values for the entire path back to the root. So if you have 3 switches, and there is a 1Gb link between switch A and switch B, and a 100 Mb link between switch B and switch C, the cost for the path is 23 (4 + 19).
If there are multiple paths to the root, the switch will use the following means of deciding which port will forward and which will block. It looks first at cost, with the lowest cost going into a forwarding state and the higher cost blocking. If there are multiple paths with the same cost, the switch will look at bridge ID, with the lowest going to forwarding state. If there are identical bridge ID's it will look at port priority, which is an arbitrarily assigned number that defaults to 128 but can be configured to choose one path over another. If there continues to be a tie, the switch will then look at port number, with the lowest interface ID going to forward packets.
Spanning-tree ports go through transitions, where each port ends either in a forwarding or blocking state. There are timers assigned to each state, and each state has a different function. They are:
Disabled - the port is obviously not forwarding
Blocking - the portaccepts BPDu's but does not send other user data
Listening - port is accepting traffic and accerpts and sends BPDU's
Learning - port is accepting traffic and entering MAC addresses into memory
Forwarding - the port is forwarding user data as well as BPDU's
To transition from blocking to listening takes 20 seconds, from listening to learning takes 15 seconds and from learning to forwarding takes another 15 seconds. When there is a topology change, STP will take 50 seconds to transition and resume network connectivity. PVSTP+ can converge in 2 seconds, but that is another topic... These timers are dictated by the root bridge, so to modify them in your network you only need to change them on the root and they will propagate throughout the network via BPDU's.
Later, VLAN's.
Monday, June 15, 2009
The date is set
June 24th, 2009 at 8:00 AM.
I was glad to see that SCSU has a testing center now. Now I can test without having to drive a couple hours beforehand.
I'm about to do some cramming, more updates later. I feel pretty good right now that I'll be prepared. I'll be going over switching and ACL's, while continuing to blast through subnetting and facts and figures. I wish I had gone over the facts and figures more, but at this point I will just need to make the most of it.
Anyway, less blogging. More studying. Opening up the labs as we speak...
I was glad to see that SCSU has a testing center now. Now I can test without having to drive a couple hours beforehand.
I'm about to do some cramming, more updates later. I feel pretty good right now that I'll be prepared. I'll be going over switching and ACL's, while continuing to blast through subnetting and facts and figures. I wish I had gone over the facts and figures more, but at this point I will just need to make the most of it.
Anyway, less blogging. More studying. Opening up the labs as we speak...
Friday, June 12, 2009
IPSec and VPN - overview
Secure network communication is of utmost importance in today's business world. Having worked in network security for the past several years, I find that the only thing that seems to trump security is cost. If something costs too much, companies are usually willing to take a risk. That's why things like HIPPA and SOX come into play, and while they sometimes make life difficult, I'm glad they are there to keep our information safe.
At any rate, IPSec is a layer 3 protocol framework that encrypts everything from layer 4 up to layer 7. I call it a framework, because it actually is a protocol that you configure other protocols to fit into to work together. This way, as encryption protocols become out-dated and compromised, IPSec can simply plug in the latest and greatest protocol and off you go!
IPSec handles encryption, which is securing your data from anyone else being able to read it. Protocols used for encryption are (ordering from weakest to strongest): DES, 3DES, AES. DES uses a 56-bit key, 3DES runs DES 3 times and AES uses 128, 192 or 256-bit encryption. These are all examples of symmetric encryption, where the key that is used to encrypt data is also used to decrypt data. Assymmetric encryption, such as PKI, uses a public/private key pair. Anything encrypted with the public key can only be decrypted with the private key and vice versa.
To solve the problem of having to configure symmetric encryption keys on all parties attempting to secure data between themselves, Diffie-Hellman Key Exchange (or DH) is used. DH works by having both clients exchange the results of a complex mathematical equation and use the results to create a secure shared key.
SSL is an encryption method that is assymmetric, using a public and private key to secure transmission of a shared secret key. Essentially, once the SSL connection is initiated, the sending party uses the receiving party's public key to encrypt a shared secret key that it generated. Only the receiver can decrypt it, because only they will have their private key.
Authentication and data integrity are handled by the older MD5 and the newer, more secure SHA-1. These protocols run a mathematical algorithm on the data to be sent, creating a "hash" that identifies the data to be sent. When the receiving party runs the algorithm against the same data, it will come up with the same hash. If the hash is different, the data has been corrupted or modified in transit and the receiving party can discard it.
Lastly, the IPSec protocol itself consists of the AH(Authentication Header) and ESP(Encapsulating Security Protocol). AH was developed first and only provided authentication and data integrity, and ESP was developed to provide encryption, which AH lacked.
VPN technologies are available in most modern versions of Cisco IOS, making them what Cisco calls "ISR" or "Integrated Security Routers." VPN technology is also included in the ASA (Adaptive Security Appliance). The 3 main benefits of using VPN technology are that: 1) it costs less to use an Internet connection to secure communication between remote sites than point-to-point leased lines, 2) provides higher speed connectivity to remote users by means of broadband and DSL connections in remote sites, compared to the old dial-up lines companies used to use, and 3) scalability is enhanced because new remote sites can be brought online without significant infrastructure enhancements. The down side to VPN technology is that the Internet is not typically as reliable as a point-to-point line, and there is increased overhead on routers and firewalls as they handle the encryption and decryption of data.
There are two types of VPNs: Site-to-site and remote-access.
Site-to-site VPN's create a secure "tunnel" through the Internet from one site to another. The users in one site have no idea what type of equipment their data passes through. As far as they are concerned, it is a direct connection. The Internet doesn't see any of the user's data, because it is encrypted before it traverses the line. These are configured to be either "permanent" or "semi-permanent" where the permanent VPN is always up, offering speed but greater overhead because the tunnel is up whether you are using it or not. Semi-permanent VPN's are brought up by the sending device when data needs to go to the remote site, and torn down wehn they are no longer in use. This takes a load off the router or firewall, but there will be some latency in the initial connection.
Remote-access VPN's are always semi-permanent. They are brought online when a user establishes a connection to the firewall or router by use of a client. Historically, they would load up a VPN client application that was configured for use by the administrator, enter their username and password (or token if 3-factor authentication is being used) and they would have network connectivity as if on the LAN. The latest and greatest method of remote-access VPN for Cisco is the SSL VPN, or WebVPN or Clientless VPN (they are all names for the same thing).
The WebVPn has a user access a secure website (watch for the https:// in the url). Once engaged in the secure web communication, they enter authentication by means of a username and password. At that point, as long as the web connection stays open they are securely connected to the LAN. In a true clientless situation,m they are presented with a directory listing in the web browser of resources to which they have access. In thin-client situations, an Active-X or java client is dlownloaded and run on the remote user, giving them the ability to use any tcp-based application on their computer. The clientless connection does not allow a user to run programs on their computer.
There is much, much, much more involved in these technologies, but from what I gather all we need for the CCNA is the broad overview and familiarity with the terms and protocols. I'll leave the in-depth analysis for my future certification blog...
At any rate, IPSec is a layer 3 protocol framework that encrypts everything from layer 4 up to layer 7. I call it a framework, because it actually is a protocol that you configure other protocols to fit into to work together. This way, as encryption protocols become out-dated and compromised, IPSec can simply plug in the latest and greatest protocol and off you go!
IPSec handles encryption, which is securing your data from anyone else being able to read it. Protocols used for encryption are (ordering from weakest to strongest): DES, 3DES, AES. DES uses a 56-bit key, 3DES runs DES 3 times and AES uses 128, 192 or 256-bit encryption. These are all examples of symmetric encryption, where the key that is used to encrypt data is also used to decrypt data. Assymmetric encryption, such as PKI, uses a public/private key pair. Anything encrypted with the public key can only be decrypted with the private key and vice versa.
To solve the problem of having to configure symmetric encryption keys on all parties attempting to secure data between themselves, Diffie-Hellman Key Exchange (or DH) is used. DH works by having both clients exchange the results of a complex mathematical equation and use the results to create a secure shared key.
SSL is an encryption method that is assymmetric, using a public and private key to secure transmission of a shared secret key. Essentially, once the SSL connection is initiated, the sending party uses the receiving party's public key to encrypt a shared secret key that it generated. Only the receiver can decrypt it, because only they will have their private key.
Authentication and data integrity are handled by the older MD5 and the newer, more secure SHA-1. These protocols run a mathematical algorithm on the data to be sent, creating a "hash" that identifies the data to be sent. When the receiving party runs the algorithm against the same data, it will come up with the same hash. If the hash is different, the data has been corrupted or modified in transit and the receiving party can discard it.
Lastly, the IPSec protocol itself consists of the AH(Authentication Header) and ESP(Encapsulating Security Protocol). AH was developed first and only provided authentication and data integrity, and ESP was developed to provide encryption, which AH lacked.
VPN technologies are available in most modern versions of Cisco IOS, making them what Cisco calls "ISR" or "Integrated Security Routers." VPN technology is also included in the ASA (Adaptive Security Appliance). The 3 main benefits of using VPN technology are that: 1) it costs less to use an Internet connection to secure communication between remote sites than point-to-point leased lines, 2) provides higher speed connectivity to remote users by means of broadband and DSL connections in remote sites, compared to the old dial-up lines companies used to use, and 3) scalability is enhanced because new remote sites can be brought online without significant infrastructure enhancements. The down side to VPN technology is that the Internet is not typically as reliable as a point-to-point line, and there is increased overhead on routers and firewalls as they handle the encryption and decryption of data.
There are two types of VPNs: Site-to-site and remote-access.
Site-to-site VPN's create a secure "tunnel" through the Internet from one site to another. The users in one site have no idea what type of equipment their data passes through. As far as they are concerned, it is a direct connection. The Internet doesn't see any of the user's data, because it is encrypted before it traverses the line. These are configured to be either "permanent" or "semi-permanent" where the permanent VPN is always up, offering speed but greater overhead because the tunnel is up whether you are using it or not. Semi-permanent VPN's are brought up by the sending device when data needs to go to the remote site, and torn down wehn they are no longer in use. This takes a load off the router or firewall, but there will be some latency in the initial connection.
Remote-access VPN's are always semi-permanent. They are brought online when a user establishes a connection to the firewall or router by use of a client. Historically, they would load up a VPN client application that was configured for use by the administrator, enter their username and password (or token if 3-factor authentication is being used) and they would have network connectivity as if on the LAN. The latest and greatest method of remote-access VPN for Cisco is the SSL VPN, or WebVPN or Clientless VPN (they are all names for the same thing).
The WebVPn has a user access a secure website (watch for the https:// in the url). Once engaged in the secure web communication, they enter authentication by means of a username and password. At that point, as long as the web connection stays open they are securely connected to the LAN. In a true clientless situation,m they are presented with a directory listing in the web browser of resources to which they have access. In thin-client situations, an Active-X or java client is dlownloaded and run on the remote user, giving them the ability to use any tcp-based application on their computer. The clientless connection does not allow a user to run programs on their computer.
There is much, much, much more involved in these technologies, but from what I gather all we need for the CCNA is the broad overview and familiarity with the terms and protocols. I'll leave the in-depth analysis for my future certification blog...
Tuesday, June 9, 2009
Checkpoint
I sat this morning and took a 30 question quiz on Frame-relay and WAN connectivity. I smoked the Frame-relay but discovered that I'm a little short on my understanding of VPN technologies. I'll be working on that this week.
I'm in the short haul here. I am planning to take the CCNA exam next week if my study goes well this week. I've shored up the routing protocols, worked through much of the L2 protocols and feel pretty good about the L1 information as far as what makes a router work, where data is stored and what kind of connectors are used in routing.
I'm also assembling a list of labs to complete before I take the exam, and I plan to focus on the troubleshooting aspects of all these technologies. I find that, in a lab situation it's easy to follow along and configure the equipment and then step back and say "Yep, it works. Now I'm an expert." Fact of the matter is, when I get into the office every day I rarely have the opportunity to set up a new enterprise routing topology. Normally I get the call that says "my network is slow" or "why can't I connect to eBay?" Knowing how to set these things up at that point is good because with no foundation it is impossible to troubleshoot, but more importantly to me is the ability to look at a configured system and figure out why it's broken or misbehaving.
So my plan for tomorrow is to take a full practice exam and figure out where I need additional work. I already know that IPSec is something I need a refresher on, and I want to lab the routing protocols and L2 protocols to death. Anyone with some experience who could tell me what else to focus on for the exam that would like to offer pointers or comments would be much appreciated.
I'm in the short haul here. I am planning to take the CCNA exam next week if my study goes well this week. I've shored up the routing protocols, worked through much of the L2 protocols and feel pretty good about the L1 information as far as what makes a router work, where data is stored and what kind of connectors are used in routing.
I'm also assembling a list of labs to complete before I take the exam, and I plan to focus on the troubleshooting aspects of all these technologies. I find that, in a lab situation it's easy to follow along and configure the equipment and then step back and say "Yep, it works. Now I'm an expert." Fact of the matter is, when I get into the office every day I rarely have the opportunity to set up a new enterprise routing topology. Normally I get the call that says "my network is slow" or "why can't I connect to eBay?" Knowing how to set these things up at that point is good because with no foundation it is impossible to troubleshoot, but more importantly to me is the ability to look at a configured system and figure out why it's broken or misbehaving.
So my plan for tomorrow is to take a full practice exam and figure out where I need additional work. I already know that IPSec is something I need a refresher on, and I want to lab the routing protocols and L2 protocols to death. Anyone with some experience who could tell me what else to focus on for the exam that would like to offer pointers or comments would be much appreciated.
Monday, June 8, 2009
Frame Relay - 2
This morning we continue our discussion about Frame Relay. Major benefits of FR are the fast transfer rates and low costs associated to it. However, a major drawback comes into play when you are using a hub-and-spoke topology where one router is the central connection point for all other connections. The problem you run into here is when you're using a distance-vector routing protocol (or hybrid protocol, such as EIGRP), split-horizon restricts routing updates from going out the same interface in which they came. That means that your "spokes" won't be able to communicate with each other.
To get around this issue, you either disable split-horizon on your hub router (which is a little bit like skydiving without a backup parachute - you can do it and probably will be OK, but if you're not...yikes!) or by configuring your router to use subinterfaces.
Subinterfaces are logical interfaces on your physical interface that the router sees and treats as separate interfaces. You configure them by adding a "." and a randomly assigned number to the end of the "interface serial 0/0" command, such as "interface serial 0/0.100". That's all it takes to create a subinterface, after which you assign it its own IP address, mask and assign the DLCI. The router then routes traffic accordingly. To do this, all you need to do is enable the appropriate encapsulation type on the physical interface and bring it up. When doing so, it is good to remember that Cisco didn't become the largest internetworking company in the world by giving away its secrets. When you configure the encapsulation type, you can choose either the proprietary "cisco" type or the industry standard "ietf" type. If all you use is Cisco, ther eis not reason to change it from teh default cisco type. If you are using multiple vendors' equipment, go with ietf.
Because serial interfaces have no MAC address, we need to somehow figure out what IP address belongs to which DLCI. If the service provider uses LMI to send a list of DLCI's that are available, the receiving router sends out inverse-arp requests that pretty much say "hello, DLCI. Send me your IP address." The remote router sends its IP address and the receiving router maps the DLCI to the IP address. Perfect. Inverse ARP is the router's automated method for figuring out which IP address goes with which DLCI. However, this method will not work when you are using mutiple PVC's on a single interface because the Inverse ARP requires that all IP addresses be under the physical interface. This causes problems with split-horizon and your routing protocol won't route and at that point you need another answer...
Enter statically mapped DLCI's. In a multipoint interface, you can map each DLCI to a subinterface, getting around the split-horizon issues. It's a little more work for the administrator, but in 3 lines of code you have configured all that is necessary for a statically mapped DLCI and your subinterfaces are all working. Wonderful.
To configure Frame Relay, you need to make sure the LMI type is the same on both ends. It is important to remember that ietf is a frame relay encapsulation type and *not* an LMI type. LMI types are cisco, ansi and q933a. These are the language that your FR routers speak to each other. Again, remember that ietf is an encapsulation type, not an LMI type.
There are four states that a frame relay circuit acn be in: ACTIVE, INACTIVE, DELETED, and STATIC. You view the state of each FR circuit by using the "show frame-relay pvc" command. This gives a table of circuits and their status, where ACTIVE means that the circuit is good and is in normal operation; INACTIVE means that your end is OK and the remote site is having problems, most likely offline or misconfigured; DELETED meaning that your side of the router is incorrectly configured (most likely an incorrect DLCI setting); and STATIC meaning that the circuit was manually entered by the administrator and not automatically discovered.
FR using a multipoint interface is configured when you add the "multipoint" argument on the end of the interface command where you create the subinterface, such as "interface serial 0.10 multipoint" which marks that subinterface as an interface that will hold multiple DLCI's. That's all fine and well, but if you have a hub and spoke topology, your spoke sites will not be able to see each other because split-horizon keeps routing updates from going out the interface on which they came. So you need to turn off split-horizon, or statically map the DLCI's by issuing the "frame-relay map ip 192.168.1.1 100 broadcast" command, where 192.168.1.1 is the remote router's IP address and 100 is the DLCI. The broadcast argument simply tells your interface not to treat the FR circuit like the NBMA network it is and to send broadcast traffic across the line.
When using Point-to-point subinterfaces, you need to create a subinterface for each PVC coming into your router. So, after enabling frame relay encapsulation on the interface, you tell the router it is a point-to-point with the obvious command "interface serial 0.100 point-to-point". After this, you assign an IP address and netmask to it, issue the "frame-relay interface-dlci 100" command and enable a routing protocol. It's as easy as that.
Frame Relay is a complex topic with much more that can be configured. But if my sources are correct, that can all wait until my CCNP blog comes out...
To get around this issue, you either disable split-horizon on your hub router (which is a little bit like skydiving without a backup parachute - you can do it and probably will be OK, but if you're not...yikes!) or by configuring your router to use subinterfaces.
Subinterfaces are logical interfaces on your physical interface that the router sees and treats as separate interfaces. You configure them by adding a "." and a randomly assigned number to the end of the "interface serial 0/0" command, such as "interface serial 0/0.100". That's all it takes to create a subinterface, after which you assign it its own IP address, mask and assign the DLCI. The router then routes traffic accordingly. To do this, all you need to do is enable the appropriate encapsulation type on the physical interface and bring it up. When doing so, it is good to remember that Cisco didn't become the largest internetworking company in the world by giving away its secrets. When you configure the encapsulation type, you can choose either the proprietary "cisco" type or the industry standard "ietf" type. If all you use is Cisco, ther eis not reason to change it from teh default cisco type. If you are using multiple vendors' equipment, go with ietf.
Because serial interfaces have no MAC address, we need to somehow figure out what IP address belongs to which DLCI. If the service provider uses LMI to send a list of DLCI's that are available, the receiving router sends out inverse-arp requests that pretty much say "hello, DLCI. Send me your IP address." The remote router sends its IP address and the receiving router maps the DLCI to the IP address. Perfect. Inverse ARP is the router's automated method for figuring out which IP address goes with which DLCI. However, this method will not work when you are using mutiple PVC's on a single interface because the Inverse ARP requires that all IP addresses be under the physical interface. This causes problems with split-horizon and your routing protocol won't route and at that point you need another answer...
Enter statically mapped DLCI's. In a multipoint interface, you can map each DLCI to a subinterface, getting around the split-horizon issues. It's a little more work for the administrator, but in 3 lines of code you have configured all that is necessary for a statically mapped DLCI and your subinterfaces are all working. Wonderful.
To configure Frame Relay, you need to make sure the LMI type is the same on both ends. It is important to remember that ietf is a frame relay encapsulation type and *not* an LMI type. LMI types are cisco, ansi and q933a. These are the language that your FR routers speak to each other. Again, remember that ietf is an encapsulation type, not an LMI type.
There are four states that a frame relay circuit acn be in: ACTIVE, INACTIVE, DELETED, and STATIC. You view the state of each FR circuit by using the "show frame-relay pvc" command. This gives a table of circuits and their status, where ACTIVE means that the circuit is good and is in normal operation; INACTIVE means that your end is OK and the remote site is having problems, most likely offline or misconfigured; DELETED meaning that your side of the router is incorrectly configured (most likely an incorrect DLCI setting); and STATIC meaning that the circuit was manually entered by the administrator and not automatically discovered.
FR using a multipoint interface is configured when you add the "multipoint" argument on the end of the interface command where you create the subinterface, such as "interface serial 0.10 multipoint" which marks that subinterface as an interface that will hold multiple DLCI's. That's all fine and well, but if you have a hub and spoke topology, your spoke sites will not be able to see each other because split-horizon keeps routing updates from going out the interface on which they came. So you need to turn off split-horizon, or statically map the DLCI's by issuing the "frame-relay map ip 192.168.1.1 100 broadcast" command, where 192.168.1.1 is the remote router's IP address and 100 is the DLCI. The broadcast argument simply tells your interface not to treat the FR circuit like the NBMA network it is and to send broadcast traffic across the line.
When using Point-to-point subinterfaces, you need to create a subinterface for each PVC coming into your router. So, after enabling frame relay encapsulation on the interface, you tell the router it is a point-to-point with the obvious command "interface serial 0.100 point-to-point". After this, you assign an IP address and netmask to it, issue the "frame-relay interface-dlci 100" command and enable a routing protocol. It's as easy as that.
Frame Relay is a complex topic with much more that can be configured. But if my sources are correct, that can all wait until my CCNP blog comes out...
Friday, June 5, 2009
Frame Relay - 1
And now, back to our program. Even though I'm running a bit short on time this morning, I wanted to drop a few quick thoughts about Frame Relay down before I lose them. Frame Relay is a popular WAN technology because it allows high data transfer rates without having to have the cost of dedicated point-to-point lines for each connection. You can have several FR links on a single interface, reducing cost yet providing a decent throughput. It is the IT manager's dream!
FR utilizes Virtual Circuits, which are logical links through a service provider's network cloud. While the path through "the cloud" may be varied and use several different devices, from the router's perspective it is a direct connection to the other end of the virtual circuit. While a packet may go through several devices between the two ends of the virtual circuit, it still sees it as one hop. Virtual circuits define which devices communicate.
Some of the tpolgies for FR are hub-and-spoke, partial mesh and full mesh. These are exactly like the "networking 101" definitions, so I won't bother to explain them. All that's required to know is that as you move from the hub-and-spoke topology to a full mesh, you increase reliability and cost.
Virtual circuits are either Permanent or Switched. A Permanent Virtual Circuit (PVC) is up all the time adn provides instantaneous data transfer. A Switched Virtual Circuit (SVC) provides data transfer on-demand. These are less common today, and an example would be an ISDN line that connects when there is data to be sent to the other end and torn down when it is inactive.
LMI (Local Management Interface) is the language two devices speak that communicate the state of virtual circuits to a router. Newer versions of IOS are able to automagically determine what LMI is in use, but in older versions it is necessary to enter it manually.
DLCI's (Direct Link Connection Identifier) are the numbers that identify where traffic is destined to reach. These are in essence used as the hardware address to identify the reciving end's network interface, because serial interfaces have no MAC address. They are locally significant only. In other words, if I know that to reach my location in Texas I send frames out virtual circuit with DLCI 100, the Texas router does not need t know what DLCI I send to. It only knows what number returns to me, and could be completely different. A great analogy that I read is one of flight numbers. A flight from Minnesota to Texas needs only be known by the Minnesotan getting on the plane. When he arrives in Texas, he is there and the flight number is unimportant now. When he wants to return to Minnesota, chances are he'll get on a plane with a completely different flight number. As long as the sending terminal knows which plane to put him on, he arrives at his destination. That's how DLCI's work. They answer the question "to get to location X, I send data to circuit Y."
Of importance to network managers is the difference between Local Access Rate and Committed Information Rate. Local access rate is another term for line speed, and is the total bandwidth of an interface. Committed Information Rate (CIR) is the service provider's guarantee for throughput, and as their lines become more heavily subscribed, they will provide at minimum this amount. An interface's local access rate will determine the realistic bandwidth available, and the CIR of all circuits cannot exceed that amount or your line is "over subscribed." When a line is over subscribed, it will allocate bandwidth to all circuits, but perhaps not meet the CIR for each. It's then time to check your SLA and monitor your throughput so you are getting all you pay for.
To keep traffic from backin up too much, service providers use BECN (Backward Explicit Congestion Notifiers) to modify the headers of traffic returning to a router to tell it to slow down its transmission. These are sent back to a transmitting router if there is a large mismatch between the Local Access Rate and the CIR, causing congestion in the line. The converse of BECN is the Forward Explicit Congestion Notifier (FECN), which is a signal from the sending router to the receiver which prompts the receiver to send a BECN in the case where there is no return traffic acknowledgement (such as in a UDP stream).
Lastly, if you are sending traffic above and beyond your CIR, a service provider may mark some of your traffic as "Discard Eligible." Marked as such, most packets still arrive safely. But if the line gets too congested, these will be the first to drop.
Tomorrow, more Frame Relay. It's a complex topic, but once you understand the terms and ideas behind it, the configuration is really quite simple. More on that later.
FR utilizes Virtual Circuits, which are logical links through a service provider's network cloud. While the path through "the cloud" may be varied and use several different devices, from the router's perspective it is a direct connection to the other end of the virtual circuit. While a packet may go through several devices between the two ends of the virtual circuit, it still sees it as one hop. Virtual circuits define which devices communicate.
Some of the tpolgies for FR are hub-and-spoke, partial mesh and full mesh. These are exactly like the "networking 101" definitions, so I won't bother to explain them. All that's required to know is that as you move from the hub-and-spoke topology to a full mesh, you increase reliability and cost.
Virtual circuits are either Permanent or Switched. A Permanent Virtual Circuit (PVC) is up all the time adn provides instantaneous data transfer. A Switched Virtual Circuit (SVC) provides data transfer on-demand. These are less common today, and an example would be an ISDN line that connects when there is data to be sent to the other end and torn down when it is inactive.
LMI (Local Management Interface) is the language two devices speak that communicate the state of virtual circuits to a router. Newer versions of IOS are able to automagically determine what LMI is in use, but in older versions it is necessary to enter it manually.
DLCI's (Direct Link Connection Identifier) are the numbers that identify where traffic is destined to reach. These are in essence used as the hardware address to identify the reciving end's network interface, because serial interfaces have no MAC address. They are locally significant only. In other words, if I know that to reach my location in Texas I send frames out virtual circuit with DLCI 100, the Texas router does not need t know what DLCI I send to. It only knows what number returns to me, and could be completely different. A great analogy that I read is one of flight numbers. A flight from Minnesota to Texas needs only be known by the Minnesotan getting on the plane. When he arrives in Texas, he is there and the flight number is unimportant now. When he wants to return to Minnesota, chances are he'll get on a plane with a completely different flight number. As long as the sending terminal knows which plane to put him on, he arrives at his destination. That's how DLCI's work. They answer the question "to get to location X, I send data to circuit Y."
Of importance to network managers is the difference between Local Access Rate and Committed Information Rate. Local access rate is another term for line speed, and is the total bandwidth of an interface. Committed Information Rate (CIR) is the service provider's guarantee for throughput, and as their lines become more heavily subscribed, they will provide at minimum this amount. An interface's local access rate will determine the realistic bandwidth available, and the CIR of all circuits cannot exceed that amount or your line is "over subscribed." When a line is over subscribed, it will allocate bandwidth to all circuits, but perhaps not meet the CIR for each. It's then time to check your SLA and monitor your throughput so you are getting all you pay for.
To keep traffic from backin up too much, service providers use BECN (Backward Explicit Congestion Notifiers) to modify the headers of traffic returning to a router to tell it to slow down its transmission. These are sent back to a transmitting router if there is a large mismatch between the Local Access Rate and the CIR, causing congestion in the line. The converse of BECN is the Forward Explicit Congestion Notifier (FECN), which is a signal from the sending router to the receiver which prompts the receiver to send a BECN in the case where there is no return traffic acknowledgement (such as in a UDP stream).
Lastly, if you are sending traffic above and beyond your CIR, a service provider may mark some of your traffic as "Discard Eligible." Marked as such, most packets still arrive safely. But if the line gets too congested, these will be the first to drop.
Tomorrow, more Frame Relay. It's a complex topic, but once you understand the terms and ideas behind it, the configuration is really quite simple. More on that later.
Wednesday, June 3, 2009
WAN Connectivity
Moving on from layer 3 protocols to layer 2, we look into (mainly) two different implementations: Cisco's proprietary HDLC and the industry standard PPP.
Of course, there is a Cisco proprietary L2 protocol. Cisco didn't get to be the world's largest internetworking company by giving its intellectual property away. If your network is all Cisco, HDLC (High-level Data Link Control) started out as an open standard, but lacked multi protocol support. Cisco took the standard and added the features it thought necessary, and made that the default encapsulation for serial interfaces on all Cisco equipment.
The nice thing about HDLC is that it is extremely simple. If you have the physical layer connected properly and both ends of the circuit are using HDLC there is nothing to get in the way. It is very efficient because it lacks any configurable options. If it was changed from HDLC on a router, you only enter "encapsulation hdlc" on the interface and it is done.
What HDLC lacks in configurability, PPP (Point-to-Point Protocol) offers. PPP gives the option of configuring authentication, call-back, compression and multi-link features to enhance your WAN network computing needs. Topping it all off, it is an open standard and allows communication between any vendor's equipment, making it the de facto standard for WAN communication.
PPP authentication comes in two varieties, either PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake Authentication Protocol). PAP is only used if you are using very old equipment, because the password is sent unencrypted in clear text, and also because the client controls the sending of the credentials. Essentially, the client makes the connection and sends the password when it is darn good and ready, after which it does not require continued authentication. This makes it vulnerable to playback attacks, where an attacker captures the data stream and sends the credentials to take over the session.
CHAP is inherently more secure because it uses MD5 hashes to secure the password, and the server (in our case, router) requests the credentials at connection and then again randomly throughout the remainder of the session. If a client device doesn't offer up the password hash when the router asks for it, the router terminates the session immediately. This prevents the playback attack, because predicting when that call for authentication iwll take place would be nearly impossible.
Call-back is just as it sounds. You set the router up to call back a remote user at a predefined number, so that when a client attempts to make a connection the router hangs up on them and dials a predefined phone number where the user with that username and password should be. If it doesn't answer, the connection is not established (obviously).
Compression is used to increase WAN bandwidth at the expense of router CPU and memory. There is the Stacker algorithm, which is a straight-forward dictionary type compression. It reads the data stream, replaces the data with a code and moves on to the next bit of data. The Predictor algorithm tries to predict the next character based on cached data that it has already compressed. This is good for connection types where the protocol does not change often. Then there is the Microsoft-proprietary MPPC which is only good for connecting Microsoft devices (blah).
Finally we have Multilink capabilities. Multilink allows PPP to combine multiple WAN links into a single, logical link. This allows you to manage and monitor a single interface for throughput, to combine anything from a couple 33.6 bps links to several T1 links for increased bandwidth, and exact-bit load balancing by chopping packets into exact-same-size fragments and sending them out across the MPPP link. TO gain this functionality you will sacrifice router CPU and memory - but what do you want for nothing? A rubber biscuit?
These features (authentication, callback, compression and multilink) are provided by one of PPP's sub-protocols. This is the LCP, or Link Control Protocol. Beneath that in the Layer 2 implementation of PPP are the NCP (Network Control Protocol) and the OSI implementation of HDLC. The OSI implementation of HDLC, like I said already, lacks support for multiple protocols, but it acts as in interface to Layer 1. From that, the NCP allows multiple network protocols to "plug in" to it by providing a standard interface. So HDLC gives the ability to support multiple devices, NCP gives PPP the ability to use multiple network protocols (think of it as a standard "jack" into which you plug in your network protocol), and LCP provides added functionality.
Later we go on to Frame-relay and ATM. What fun!
Hi Geoff...
Of course, there is a Cisco proprietary L2 protocol. Cisco didn't get to be the world's largest internetworking company by giving its intellectual property away. If your network is all Cisco, HDLC (High-level Data Link Control) started out as an open standard, but lacked multi protocol support. Cisco took the standard and added the features it thought necessary, and made that the default encapsulation for serial interfaces on all Cisco equipment.
The nice thing about HDLC is that it is extremely simple. If you have the physical layer connected properly and both ends of the circuit are using HDLC there is nothing to get in the way. It is very efficient because it lacks any configurable options. If it was changed from HDLC on a router, you only enter "encapsulation hdlc" on the interface and it is done.
What HDLC lacks in configurability, PPP (Point-to-Point Protocol) offers. PPP gives the option of configuring authentication, call-back, compression and multi-link features to enhance your WAN network computing needs. Topping it all off, it is an open standard and allows communication between any vendor's equipment, making it the de facto standard for WAN communication.
PPP authentication comes in two varieties, either PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake Authentication Protocol). PAP is only used if you are using very old equipment, because the password is sent unencrypted in clear text, and also because the client controls the sending of the credentials. Essentially, the client makes the connection and sends the password when it is darn good and ready, after which it does not require continued authentication. This makes it vulnerable to playback attacks, where an attacker captures the data stream and sends the credentials to take over the session.
CHAP is inherently more secure because it uses MD5 hashes to secure the password, and the server (in our case, router) requests the credentials at connection and then again randomly throughout the remainder of the session. If a client device doesn't offer up the password hash when the router asks for it, the router terminates the session immediately. This prevents the playback attack, because predicting when that call for authentication iwll take place would be nearly impossible.
Call-back is just as it sounds. You set the router up to call back a remote user at a predefined number, so that when a client attempts to make a connection the router hangs up on them and dials a predefined phone number where the user with that username and password should be. If it doesn't answer, the connection is not established (obviously).
Compression is used to increase WAN bandwidth at the expense of router CPU and memory. There is the Stacker algorithm, which is a straight-forward dictionary type compression. It reads the data stream, replaces the data with a code and moves on to the next bit of data. The Predictor algorithm tries to predict the next character based on cached data that it has already compressed. This is good for connection types where the protocol does not change often. Then there is the Microsoft-proprietary MPPC which is only good for connecting Microsoft devices (blah).
Finally we have Multilink capabilities. Multilink allows PPP to combine multiple WAN links into a single, logical link. This allows you to manage and monitor a single interface for throughput, to combine anything from a couple 33.6 bps links to several T1 links for increased bandwidth, and exact-bit load balancing by chopping packets into exact-same-size fragments and sending them out across the MPPP link. TO gain this functionality you will sacrifice router CPU and memory - but what do you want for nothing? A rubber biscuit?
These features (authentication, callback, compression and multilink) are provided by one of PPP's sub-protocols. This is the LCP, or Link Control Protocol. Beneath that in the Layer 2 implementation of PPP are the NCP (Network Control Protocol) and the OSI implementation of HDLC. The OSI implementation of HDLC, like I said already, lacks support for multiple protocols, but it acts as in interface to Layer 1. From that, the NCP allows multiple network protocols to "plug in" to it by providing a standard interface. So HDLC gives the ability to support multiple devices, NCP gives PPP the ability to use multiple network protocols (think of it as a standard "jack" into which you plug in your network protocol), and LCP provides added functionality.
Later we go on to Frame-relay and ATM. What fun!
Hi Geoff...
Tuesday, June 2, 2009
EIGRP thoughts
EIGRP (Enhanced Interior Gateway Protocol) is a Cisco proprietary routing protocol. It is a hybrid between distance-vector and link-state protocols, incorporating the best from both worlds.
This protocol is able to route multiple protocols, such as IP, IPX, Appletalk (should you ever need to route Appletalk...), but the biggest difference in how EIGRP computes the metric. It uses a combination of bandwidth and delay, each multiplied by 255 to give a 32-bit metric to determine the best path to any given destination. You can also add in other factors, such as load, MTU and reliability to further enhance the routing decisions. It is also capable of unequal load balancing, splitting up traffic according to available bandwidth, over six paths compared to OSPF and RIP's equal load balancing, and it has a maximum hop count of 244 compared to RIP's 15. Also, EIGRP is classfull by default but can be configured as classless (like RIPv2) by issuing the "no auto-summary" command.
It discovers neighbors using multicast packets to 224.0.0.10, and like OSPF stores the data in a topology table. Once the topolgy tables are in sync, they send out hello packets to keep their dead timers from expiring. Like OSPF, the hello and dead timers differ based on the topology of the network. Multi-access broadcast and point-to-point networks have a hello timer of 5 seconds and a dead timer of 15 seconds, while non-broadcast multi-access have a 60 and 180 hello and dead timer, respectively. The dead timer is 3 times the hello timer, which helps me remember for some reason. Worth noting as well is that it uses the Diffusing Update Algorithm (or DUAL) to compute topology changes in a fractions of a second.
The reason EIGRP can converge so quickly when the topolgy changes is that it chooses a successor route and also a feasible successor. The feasible successor is a backup route in case the successor goes down. It does this by tracking the metric from each neighbor router to all routes advertised by its neighbor. That is the advertised distance. It then adds its composite metric to the advertised distance to come up with the feasible distance. The lowest feasible distance is then added to the route table as the successor. To become the feasible successor, a route must have a lower advertised distance than the feasible distance of the successor route.
Along with calculating the feasible successor route to speed convergence in the case of a link going down, EIGRP has another efficiency over OSPF. In the case of multiple routes to a given network, but no advertised distance is lower than the feasible distance (thereby causing EIGRP to have no feasible successor), EIGRP handles the down link differently than OSPF. OSPF would flood the link state to all routers in the area, consuming considerable amounts of bandwidth and processing power. EIGRP simply queries its neighbors for a route to that path and the router with the down link and then computes a successor path based on the information it receives in return. Of course, it must not create a loop and has to wait out the "Stuck in Active" timer of 180 seconds (which also would exceed the dead timer in a NBMA network) to make sure it gets every possible reply.
Like OSPF, EIGRP also utilizes stub networks to allow route summarization where there is only one path in and out of a network. If the only link to a network goes down, it doesn't do any good to start querying neighbors for another route.
Configuring EIGRP is quite simple in its most basic form. Like RIP, you simply initialize the protocol using the "router" command. The major difference here is that EIGRP requires an Autonomous System number the must be the same on all EIGRP routers or they will not get the updates from one another. Contrast this with OSPF's process ID, because they come in the same location of the router command:
EIGRP
RouterA(config)#router eigrp 100
100 is the randomly assigned AS number. It is randomly assigned by the planner of the network, by the way.
OSPF
RouterA(config)#router ospf 100
In this case, 100 is the process ID which does not need to match anything else. Any network advertised in a given area will update with OSPF.
From here, it is imperative to configure the bandwidth of serial links correctly, since Cisco IOS assumes all serial links are T1's. Ethernet interfaces report their bandwidth accurately. It is also important to remember that, if configuring a network as a stub network, you need to turn off the auto-summarization or manually configure a summary route. Also for contrast, to veiw OSPF's topolgy table you enter "show ip ospf database" where in EIGRP you enter "show ip eigrp topology" which just makes more sense to me. I believe in "calling it what it is"...
With all that said, there are only two drawbacks to EIGRP. One is that you cannot use multiple vendors' equipment. EIGRP is Cisco-only. The other thing is that it consumes a lot fo processing and memory because it maintains a topolgy, neighbor and routing table for each protocol being routed. While that isn't a big deal now that the world is run on IP, it could be a consideration.
EIGRP is a nice protocol, efficient and easy to configure. If you only have Cisco equipment, it only makes sense. Unless you are like me and really loathe using proprietary protocols to base your infrastructure upon. I just like having options.
This protocol is able to route multiple protocols, such as IP, IPX, Appletalk (should you ever need to route Appletalk...
It discovers neighbors using multicast packets to 224.0.0.10, and like OSPF stores the data in a topology table. Once the topolgy tables are in sync, they send out hello packets to keep their dead timers from expiring. Like OSPF, the hello and dead timers differ based on the topology of the network. Multi-access broadcast and point-to-point networks have a hello timer of 5 seconds and a dead timer of 15 seconds, while non-broadcast multi-access have a 60 and 180 hello and dead timer, respectively. The dead timer is 3 times the hello timer, which helps me remember for some reason. Worth noting as well is that it uses the Diffusing Update Algorithm (or DUAL) to compute topology changes in a fractions of a second.
The reason EIGRP can converge so quickly when the topolgy changes is that it chooses a successor route and also a feasible successor. The feasible successor is a backup route in case the successor goes down. It does this by tracking the metric from each neighbor router to all routes advertised by its neighbor. That is the advertised distance. It then adds its composite metric to the advertised distance to come up with the feasible distance. The lowest feasible distance is then added to the route table as the successor. To become the feasible successor, a route must have a lower advertised distance than the feasible distance of the successor route.
Along with calculating the feasible successor route to speed convergence in the case of a link going down, EIGRP has another efficiency over OSPF. In the case of multiple routes to a given network, but no advertised distance is lower than the feasible distance (thereby causing EIGRP to have no feasible successor), EIGRP handles the down link differently than OSPF. OSPF would flood the link state to all routers in the area, consuming considerable amounts of bandwidth and processing power. EIGRP simply queries its neighbors for a route to that path and the router with the down link and then computes a successor path based on the information it receives in return. Of course, it must not create a loop and has to wait out the "Stuck in Active" timer of 180 seconds (which also would exceed the dead timer in a NBMA network) to make sure it gets every possible reply.
Like OSPF, EIGRP also utilizes stub networks to allow route summarization where there is only one path in and out of a network. If the only link to a network goes down, it doesn't do any good to start querying neighbors for another route.
Configuring EIGRP is quite simple in its most basic form. Like RIP, you simply initialize the protocol using the "router" command. The major difference here is that EIGRP requires an Autonomous System number the must be the same on all EIGRP routers or they will not get the updates from one another. Contrast this with OSPF's process ID, because they come in the same location of the router command:
EIGRP
RouterA(config)#router eigrp 100
100 is the randomly assigned AS number. It is randomly assigned by the planner of the network, by the way.
OSPF
RouterA(config)#router ospf 100
In this case, 100 is the process ID which does not need to match anything else. Any network advertised in a given area will update with OSPF.
From here, it is imperative to configure the bandwidth of serial links correctly, since Cisco IOS assumes all serial links are T1's. Ethernet interfaces report their bandwidth accurately. It is also important to remember that, if configuring a network as a stub network, you need to turn off the auto-summarization or manually configure a summary route. Also for contrast, to veiw OSPF's topolgy table you enter "show ip ospf database" where in EIGRP you enter "show ip eigrp topology" which just makes more sense to me. I believe in "calling it what it is"...
With all that said, there are only two drawbacks to EIGRP. One is that you cannot use multiple vendors' equipment. EIGRP is Cisco-only. The other thing is that it consumes a lot fo processing and memory because it maintains a topolgy, neighbor and routing table for each protocol being routed. While that isn't a big deal now that the world is run on IP, it could be a consideration.
EIGRP is a nice protocol, efficient and easy to configure. If you only have Cisco equipment, it only makes sense. Unless you are like me and really loathe using proprietary protocols to base your infrastructure upon. I just like having options.
Monday, June 1, 2009
OSPF thoughts
Open Shortest Path First (OSPF) is a widely-used link-state routing protocol. It is vendor neutral, which contributes to its popularity, since many large networks include equipment from various manufacturers.
OSPF is completely classless - so it incorporates networks and subnet masks into its routing updates and topology tables, and this information is used in the computing of the shortest path to any given network. That is a nice thing about OSPF, since you don't have to worry too much about dis-contiguous networks. You simply add the netmask to the network you plan to advertise in OSPF and the router does the rest of the work.
The down side is that computing the shortest path for all known networks is resource intensive, and in the event of a link going down, the state of that link is flooded to all routers inside the area, and the Dijkstra's Shortest Path First algorithm is run by them all. This takes a lot of memory and CPU power, which can cause a slowdown in your network if it is large. If you have a link "flapping," or going up and down rapidly, this can cause an unstable condition as each router computes and recomputes the paths each time it receives an update (or LSU - link state update).
To mitigate this condition on broadcast multi-access networks and non-broadcast multi-access networks (such as frame relay), OSPF elects a Designated Router and a Backup Designated Router in case the DR fails. This election is won by the device with the numerically largest IP address on the network. OSPF first will calculate the DR/BDR from the logical interfaces and then the physical interfaces, so often times a router will be configured first with a logical loopback address to function as the router ID. On point-to-point networks, where there are only two devices on the network, there is no need for an election. The beauty of this is that any link state updates are sent only to the DR and BDR, and these routers then send the update the remaining routers in its area. Updates are flooded out on multicast addresses: 224.0.0.6 for the DR/BDR updates and then they send updates out to 224.0.0.5, which is the multicast address for all OSPF routers.
Other points of note in configuring ospf is that, when you initiate ospf by entering "router ospf" in global config mode on your router, you specify a "process id," which is a number between 1-65,535. This number is only important to the individual router. It is not advertised to other routers, and does not need to be the same on each router within an area. OSPF uses areas to associate routers together, which gets configured when entering the network to be advertised. All areas must somehow connect to Area 0, which is the backbone area for the OSPF autonomous system.
When configuring OSPF, also of great importance is the use of wildcard masks, which is the opposite of a subnet mask. In essence, a 1 in a subnet mask means "ignore this bit" and a 0 means "check this bit." When you enter a wildcard mask of 0.0.0.255, the router will act on any packet that matches the first three octets of the IP address, with anything in the last octet being a match since it is ignored. So, to advertise the 192.168.1.0/24 network, we would enter the following command after the "router ospf 4" command (the 4 is arbitrary and the process ID for this instance of OSPF on this router):
network 192.168.1.0 0.0.0.255 area 0
This puts all 192.168.1.0 traffic in our backbone area 0.
There is much more about OSPF to know, and these are really just simply my summarization of interesting points. A greater discussion of areas, LSA/LSU's and elections could be had. The main points are that OSPF is a link-state routing protocol that is completely classless, advertises the netmask along with the subnet and interoperates with multiple vendors' equipment because it is non-proprietary. From there you just need to draw it out and configure it a few times...
OSPF is completely classless - so it incorporates networks and subnet masks into its routing updates and topology tables, and this information is used in the computing of the shortest path to any given network. That is a nice thing about OSPF, since you don't have to worry too much about dis-contiguous networks. You simply add the netmask to the network you plan to advertise in OSPF and the router does the rest of the work.
The down side is that computing the shortest path for all known networks is resource intensive, and in the event of a link going down, the state of that link is flooded to all routers inside the area, and the Dijkstra's Shortest Path First algorithm is run by them all. This takes a lot of memory and CPU power, which can cause a slowdown in your network if it is large. If you have a link "flapping," or going up and down rapidly, this can cause an unstable condition as each router computes and recomputes the paths each time it receives an update (or LSU - link state update).
To mitigate this condition on broadcast multi-access networks and non-broadcast multi-access networks (such as frame relay), OSPF elects a Designated Router and a Backup Designated Router in case the DR fails. This election is won by the device with the numerically largest IP address on the network. OSPF first will calculate the DR/BDR from the logical interfaces and then the physical interfaces, so often times a router will be configured first with a logical loopback address to function as the router ID. On point-to-point networks, where there are only two devices on the network, there is no need for an election. The beauty of this is that any link state updates are sent only to the DR and BDR, and these routers then send the update the remaining routers in its area. Updates are flooded out on multicast addresses: 224.0.0.6 for the DR/BDR updates and then they send updates out to 224.0.0.5, which is the multicast address for all OSPF routers.
Other points of note in configuring ospf is that, when you initiate ospf by entering "router ospf" in global config mode on your router, you specify a "process id," which is a number between 1-65,535. This number is only important to the individual router. It is not advertised to other routers, and does not need to be the same on each router within an area. OSPF uses areas to associate routers together, which gets configured when entering the network to be advertised. All areas must somehow connect to Area 0, which is the backbone area for the OSPF autonomous system.
When configuring OSPF, also of great importance is the use of wildcard masks, which is the opposite of a subnet mask. In essence, a 1 in a subnet mask means "ignore this bit" and a 0 means "check this bit." When you enter a wildcard mask of 0.0.0.255, the router will act on any packet that matches the first three octets of the IP address, with anything in the last octet being a match since it is ignored. So, to advertise the 192.168.1.0/24 network, we would enter the following command after the "router ospf 4" command (the 4 is arbitrary and the process ID for this instance of OSPF on this router):
network 192.168.1.0 0.0.0.255 area 0
This puts all 192.168.1.0 traffic in our backbone area 0.
There is much more about OSPF to know, and these are really just simply my summarization of interesting points. A greater discussion of areas, LSA/LSU's and elections could be had. The main points are that OSPF is a link-state routing protocol that is completely classless, advertises the netmask along with the subnet and interoperates with multiple vendors' equipment because it is non-proprietary. From there you just need to draw it out and configure it a few times...
Friday, May 29, 2009
Routing - Link State Protocols
Link State protocols differ from Distance-Vector protocols in several ways, but in a nutshell a link state protocol uses a different and complex mathematical formula to compute the best route to a given network based on the actual condition of the network (or rather, the "state of the link"). Where distance-vector protocols gather their information by obtaining all possible routes that their neighbours provide, link state protocols discover their neighbours and keep the information from them in a neighbour table. Their neighbours update the condition of the networks they have knowledge of, and each router then uses Dijkstra's "Shortest Path First" algorithm to compute the best route. An example of a link-state protocol is Open Shortest Path First, or OSPF, which is an industry standard protocol that can be used between any vendor's equipment.
LS protocols send out Link State Announcements, or LSA's when they first come on line, this alerts their neighbours that they exist and that there are networks connected to them. Because each router needs to update their own routing table based on the state of their neighbours, this is a very processor-intense operation. The nice thing about LS protocols is that this only happens when there is a change in the topology (contained in the topology table which holds all possible routes to all possible networks). The updates are sent in Link State Updates, or LSU's.
One reason that LS protocols are much faster to converge than Distance Vector protocols is that a link state protocol, when it receives an update of a change in topology via LSU, forwards that info out to all its neighbours even before updating its own topology table. Getting the info out takes precedence, so all routers know the condition of the network before bothering to change their own routing tables.
LS protocols also do not send out regular updates like distance vector protocols do. They only send out changes when they occur, so once the network is converged there is very little network management traffic. Routers only send out small LSA Hello packets to make sure everyone is still alive and well.
To keep routing tables manageable and link state calculation to a reasonable time frame, LS protocols are typically separated into sections, or Areas. These areas are connected to a single area (called a backbone area), and routers in each area only maintain a topology table for other routers in their area. Between these areas, routes are summarized to keep tables manageable.
I'll be looking more in-depth at the actual protocols and perhaps comparing and contrasting them a bit in the upcoming posts.
LS protocols send out Link State Announcements, or LSA's when they first come on line, this alerts their neighbours that they exist and that there are networks connected to them. Because each router needs to update their own routing table based on the state of their neighbours, this is a very processor-intense operation. The nice thing about LS protocols is that this only happens when there is a change in the topology (contained in the topology table which holds all possible routes to all possible networks). The updates are sent in Link State Updates, or LSU's.
One reason that LS protocols are much faster to converge than Distance Vector protocols is that a link state protocol, when it receives an update of a change in topology via LSU, forwards that info out to all its neighbours even before updating its own topology table. Getting the info out takes precedence, so all routers know the condition of the network before bothering to change their own routing tables.
LS protocols also do not send out regular updates like distance vector protocols do. They only send out changes when they occur, so once the network is converged there is very little network management traffic. Routers only send out small LSA Hello packets to make sure everyone is still alive and well.
To keep routing tables manageable and link state calculation to a reasonable time frame, LS protocols are typically separated into sections, or Areas. These areas are connected to a single area (called a backbone area), and routers in each area only maintain a topology table for other routers in their area. Between these areas, routes are summarized to keep tables manageable.
I'll be looking more in-depth at the actual protocols and perhaps comparing and contrasting them a bit in the upcoming posts.
Thursday, May 28, 2009
Routing loops mitigated - Distance Vector Protocols
To keep your data from floating around in never-ending loops, there are a few methods used by Distance-Vector protocols to avoid looping. They are:
Hop Counts
When a routing protocol sends its routing table to its neighbors, it increases teh hop counts on connected routes by one each time. In the case of a network that is unavailable or looped, this could go on forever (a scenario known as "counting to infinity"). Maximum hop counts are the most basic of the mitigation methods for DV protocols. This way, once a hop count metric reaches the max value, the route is assumed as unavailable.
Maximum hop counts are:
RIP v1 and v2 15
EIGRP 224
Split-horizon
This one, simply stated is to not advertise a route out the same interface in which it came. If I tell you that I am connected to network 192.168.1.0/24, why would I tell you that 192.168.1.0/24 is one router away from me? First, you already know where it is, and because I increment the hop count, you would now think that 192.168.1.0/24 is *two* hops away from me.
Route Poisoning
When a link fails, the router to which it is attached sends out a routing update with a hop count that exceeds the maximum value for that protocol. So, if I have a router connected to 192.168.2.0/24, and the interface connected to that network fails, I send an update to my neighbors incrementing the hop count for that network to 16. Then all my neighbors know it is unavailable. Cool.
Poison Reverse
Poison reverse overrides the split-horizon rule and sends the route update back out the interface on which it came. This provides an acknowledgement that the device received the change to the topology.
Hold-down Timers
Simply stated, hold-down timers store an update for a given amount of time before adding the change to their routing table. The idea is that, should a link start going up and down rapidly (otherwise known as "flapping"), the link will come up before the timer expires and there is no need to change the routing table. If the timer expires and the router doesn't hear of a route with a lower metric, it adds the route to its table.
Triggered Updates
To speed convergence of the network, a triggered update allows a router to send an update in the event of a failed link instead of waiting for the regular update. This allows the network to react more quickly to topology changes.
Invalid/Dead Timers
When a device is removed from the network but doesn't fail, a triggered update isn't sent, so the remaining routers may think the device still exists. To combat this, when a router stops receiving updates from another router, after a certain amount of time the router is considered "dead" and the routes are invalid. The routes are then removed from the table. This method is also used in the case where a router stops receiving updates from a given routing protocol but is no longer. Perhaps we changed our topology and started to use EIGRP instead of RIP, and after that set amount of time the RIP-learned routes are considered invalid and removed.
Tomorrow, more routing protocols! I know you can hardly wait, Bear...
Hop Counts
When a routing protocol sends its routing table to its neighbors, it increases teh hop counts on connected routes by one each time. In the case of a network that is unavailable or looped, this could go on forever (a scenario known as "counting to infinity"). Maximum hop counts are the most basic of the mitigation methods for DV protocols. This way, once a hop count metric reaches the max value, the route is assumed as unavailable.
Maximum hop counts are:
RIP v1 and v2 15
EIGRP 224
Split-horizon
This one, simply stated is to not advertise a route out the same interface in which it came. If I tell you that I am connected to network 192.168.1.0/24, why would I tell you that 192.168.1.0/24 is one router away from me? First, you already know where it is, and because I increment the hop count, you would now think that 192.168.1.0/24 is *two* hops away from me.
Route Poisoning
When a link fails, the router to which it is attached sends out a routing update with a hop count that exceeds the maximum value for that protocol. So, if I have a router connected to 192.168.2.0/24, and the interface connected to that network fails, I send an update to my neighbors incrementing the hop count for that network to 16. Then all my neighbors know it is unavailable. Cool.
Poison Reverse
Poison reverse overrides the split-horizon rule and sends the route update back out the interface on which it came. This provides an acknowledgement that the device received the change to the topology.
Hold-down Timers
Simply stated, hold-down timers store an update for a given amount of time before adding the change to their routing table. The idea is that, should a link start going up and down rapidly (otherwise known as "flapping"), the link will come up before the timer expires and there is no need to change the routing table. If the timer expires and the router doesn't hear of a route with a lower metric, it adds the route to its table.
Triggered Updates
To speed convergence of the network, a triggered update allows a router to send an update in the event of a failed link instead of waiting for the regular update. This allows the network to react more quickly to topology changes.
Invalid/Dead Timers
When a device is removed from the network but doesn't fail, a triggered update isn't sent, so the remaining routers may think the device still exists. To combat this, when a router stops receiving updates from another router, after a certain amount of time the router is considered "dead" and the routes are invalid. The routes are then removed from the table. This method is also used in the case where a router stops receiving updates from a given routing protocol but is no longer. Perhaps we changed our topology and started to use EIGRP instead of RIP, and after that set amount of time the RIP-learned routes are considered invalid and removed.
Tomorrow, more routing protocols! I know you can hardly wait, Bear...
Routing Protocols review - metric
This morning I reviewed routing protocols again, which should be known but I want to make sure I'm absolutely clear on this since it is the foundation of routing.
After being clear on Administrative Distance yesterday, this morning I wanted to make sure I understood what was being described by "Metric," which is something you see in a route table when you execute a "show ip route" command. So for instance, you might get output that looks like:
R 172.17.0.0/16 [120/1] via 192.168.1.10, Serial0/0/0
This is telling us that the network 172.17.0.0/16 was learned using RIP, that its Administrative Distance is 120, the metric is 1, and that it came from 192.168.1.10 (the IP address of our neighbouring router) through the Serial 0/0/0 interface (on our router). Cool enough.
The Administrative Distance is the number that Cisco IOS uses to determine the most reliable route to the network with the lower AD being the more reliable. The *metric* is what the routing protocol uses to determine the best path to that network. So, if we learned about the 172.17.0.0/16 network through another interface, indicating we had multiple paths to that network, and that path was using RIP also, RIP would choose the path with the lowest metric and place that in the routing table. So, if RIP had another entry that looked like:
R 172.17.0.0/16 [120/3] via 192.168.1.129, Serial0/0/1
it would place the route with the lowest metric into the table and use it for any traffic destined for that network. It is then important to know how each routing protocol determines its metric - RIP uses "hop count," or a count of the number of networking devices between the source and the destination networks. Our first entry tells us that there is one router between source and destination, while the second tells us there are 3. Going through one stop theoretically is faster than going through 3, right?
So, that is what the metric is. Administrative Distance is used by IOS to determine the most reliable path based on routing protocol, and metric is used within a routing protocol to determine the most efficient path.
I probably could have just summarized that and saved 15 minutes of typing...
After being clear on Administrative Distance yesterday, this morning I wanted to make sure I understood what was being described by "Metric," which is something you see in a route table when you execute a "show ip route" command. So for instance, you might get output that looks like:
R 172.17.0.0/16 [120/1] via 192.168.1.10, Serial0/0/0
This is telling us that the network 172.17.0.0/16 was learned using RIP, that its Administrative Distance is 120, the metric is 1, and that it came from 192.168.1.10 (the IP address of our neighbouring router) through the Serial 0/0/0 interface (on our router). Cool enough.
The Administrative Distance is the number that Cisco IOS uses to determine the most reliable route to the network with the lower AD being the more reliable. The *metric* is what the routing protocol uses to determine the best path to that network. So, if we learned about the 172.17.0.0/16 network through another interface, indicating we had multiple paths to that network, and that path was using RIP also, RIP would choose the path with the lowest metric and place that in the routing table. So, if RIP had another entry that looked like:
R 172.17.0.0/16 [120/3] via 192.168.1.129, Serial0/0/1
it would place the route with the lowest metric into the table and use it for any traffic destined for that network. It is then important to know how each routing protocol determines its metric - RIP uses "hop count," or a count of the number of networking devices between the source and the destination networks. Our first entry tells us that there is one router between source and destination, while the second tells us there are 3. Going through one stop theoretically is faster than going through 3, right?
So, that is what the metric is. Administrative Distance is used by IOS to determine the most reliable path based on routing protocol, and metric is used within a routing protocol to determine the most efficient path.
I probably could have just summarized that and saved 15 minutes of typing...
Wednesday, May 27, 2009
Routing - things I should have known
Funny how you go through life thinking that you know an awful lot, only to find out that you don't know nearly as much as you did, making you question everything you actually do know...
Anyhow, I was reading up on static routes for the CCNA tonight. Breezing over things, I saw something that I had never really considered before, though I instantly saw how this was going to help me do my job a little better.
I thought there was not much more to a static route entry than to specify the network you wanted to route to, the netmask and the IP address to send that traffic toward. For instance:
ip route 192.168.1.0 255.255.255.0 10.1.1.1
sends anything destined for the 192.168.1.0/24 network to an interface with IP address 10.1.1.1. Woo-hoo, right? Well, now I've learned about Floating Static Routes. By adding a parameter at the end of the ip route statement, you can set the administrative distance for the route than the default value of 1 for a statically-assigned route. So now our command becomes:
ip route 192.168.1.0 255.255.255.0 10.1.1.2 2
The "2" at the end of that statement makes this route slightly higher in administrative distance, and that route will not be added to the routing table unless the first route goes down. This is useful if you have multiple links to get to the same location, such as two different ISP's (multiple default routes) or multiple paths to your remote offices. So, along with that, let's run down the default administrative distances for ip routes in Cisco IOS:
Route type Administrative distance
==============================================
Connected interface 0
Static route 1
EIGRP summary 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP (v1 and v2) 120
EGP 140
External EIGRP 170
When a router learns of the same destination through multiple routing protocols, it will choose the path with the lowest administrative distance.
Perhaps more later. I've been solidifying my understanding of the show ip route output today, also, but like I said...I feel like I should know this stuff already. Ah well, it's good to learn and better to know what the heck you're talking about should a client ask "What does that number mean there, after the IP address?"
Good night, all.
Anyhow, I was reading up on static routes for the CCNA tonight. Breezing over things, I saw something that I had never really considered before, though I instantly saw how this was going to help me do my job a little better.
I thought there was not much more to a static route entry than to specify the network you wanted to route to, the netmask and the IP address to send that traffic toward. For instance:
ip route 192.168.1.0 255.255.255.0 10.1.1.1
sends anything destined for the 192.168.1.0/24 network to an interface with IP address 10.1.1.1. Woo-hoo, right? Well, now I've learned about Floating Static Routes. By adding a parameter at the end of the ip route statement, you can set the administrative distance for the route than the default value of 1 for a statically-assigned route. So now our command becomes:
ip route 192.168.1.0 255.255.255.0 10.1.1.2 2
The "2" at the end of that statement makes this route slightly higher in administrative distance, and that route will not be added to the routing table unless the first route goes down. This is useful if you have multiple links to get to the same location, such as two different ISP's (multiple default routes) or multiple paths to your remote offices. So, along with that, let's run down the default administrative distances for ip routes in Cisco IOS:
Route type Administrative distance
==============================================
Connected interface 0
Static route 1
EIGRP summary 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP (v1 and v2) 120
EGP 140
External EIGRP 170
When a router learns of the same destination through multiple routing protocols, it will choose the path with the lowest administrative distance.
Perhaps more later. I've been solidifying my understanding of the show ip route output today, also, but like I said...I feel like I should know this stuff already. Ah well, it's good to learn and better to know what the heck you're talking about should a client ask "What does that number mean there, after the IP address?"
Good night, all.
Tuesday, May 26, 2009
Studying again
I am preparing to take my CCNA (Cisco Certified Network Associate) in the next few weeks. I've been preparing for this for about 60 days now, and with summer coming up I'm feeling the pinch to do other things besides sitting in front of this computer with emulated routing and switching labs. But this needs to be completed soon, so I'll bear with it.
Right now I'm using a really excellent study tool called GNS3, and this is a real money saver. It's an emulation environment for Cisco IOS that runs actual IOS images as opposed to running simulated IOS. I found that, although some other router sims were quite good, they lacked in flexibility and completeness of the IOS command set. It is good to follow a canned lab, executing the required commands and nothing else. It's a whole other thing to set up a lab yourself and emulate a real-world environment. I have a number of labs created that I'm planning to put the finishing touches on and upload to GNS3-labs, which has been a really great tool for learning how to make GNS3 perform at its highest.
I'm in the final days of cramming, as I"ve already been thorough the majority of the material. I'm hoping to blog here about my topics of study to clarify what I'm learning for myself and perhaps to assist others in their own attempts. I find that there is a lot of material on the web pertaining to the CCIE, but not as much for the entry-level certs. (For that matter, I'd recommend not using Paul Browning's web site, book or racks. His material is lacking depth, his book is full of errors and his racks didn't function well. When I asked for a refund, he became condescending, insulting and childish. I'd be happy to show my correspondence with this unprofessional individual should anyone care to see it).
So, at any rate, on to the books and a little WAN theory tonight.
Right now I'm using a really excellent study tool called GNS3, and this is a real money saver. It's an emulation environment for Cisco IOS that runs actual IOS images as opposed to running simulated IOS. I found that, although some other router sims were quite good, they lacked in flexibility and completeness of the IOS command set. It is good to follow a canned lab, executing the required commands and nothing else. It's a whole other thing to set up a lab yourself and emulate a real-world environment. I have a number of labs created that I'm planning to put the finishing touches on and upload to GNS3-labs, which has been a really great tool for learning how to make GNS3 perform at its highest.
I'm in the final days of cramming, as I"ve already been thorough the majority of the material. I'm hoping to blog here about my topics of study to clarify what I'm learning for myself and perhaps to assist others in their own attempts. I find that there is a lot of material on the web pertaining to the CCIE, but not as much for the entry-level certs. (For that matter, I'd recommend not using Paul Browning's web site, book or racks. His material is lacking depth, his book is full of errors and his racks didn't function well. When I asked for a refund, he became condescending, insulting and childish. I'd be happy to show my correspondence with this unprofessional individual should anyone care to see it).
So, at any rate, on to the books and a little WAN theory tonight.
Subscribe to:
Posts (Atom)