Posts Tagged ‘CCIE’
Let’s Review: OSPF LSA Types
With my Written exam for CCIE: R/S coming up soon (Cisco Live 2015) I figured this would be a good time to back over some basics, and when it comes to OSPF what is more basic than OSPF LSA Types!
LSA Type 1 – These are also known as Router LSA’s, every router participating in OSPF will generate one of these, and Type 1 LSA’s are flooded within the area that the router belongs. So, what is it the Type 1 LSA tells us:
- Certain capabilities, is the router a Border router or ASBR. (Respective E-bit and B-bit)
- Does the router terminate a virtual link (V-bit)
- Number of links
- Link types – PtP, Virtual, etc
- Link Cost/Metric
So lot’s of good information in LSA-1, think of these as a ‘blue-print’ of the router, describing what is has and what it is doing.
LSA Type 2 – Network LSA’s. These LSA types are generated by the DR (Designated Router) and one type-2 LSA is generated for every network with two or more OSPF neighbors. You can expect to find these when you multiple devices connected to a broadcast network (A.K.A. LAN) or on an NMBA network (Frame Relay/DMVPN). Type-2 LSA’s will include information about the attached routers along with information of the network segment. This LSA is just an informative one, letting you know what other Routers you are connected to along, no metric/cost information is included in a Type-2 LSA.
LSA Type 3 – Summary LSA’s. Type-3’s are generated by ABR’s and are used to extend reachable to other OSPF areas. Remember LSA Type-1’s are limited to the area that they originate them in. They also designate Inter-Area connectivity as opposed to Intra-Area connectivity. A good rule of thumb is for every route in the routing table, there should be an associated Type-3 LSA in the OSPF LSDB.
LSA Type 4 – Think of these as Type-3 LSAs however instead of being generated by ABRs they are generated from ASBRs. Type-3 & Type-4 LSA’s use the exact same format, however the differentiating factor is the fact, a Type-4 Link State ID is the Router-ID of the ASBR. (Where-as a Type 3 LSA will/may have a Link State ID of the IP Network)
Similarities in Type-3 & 4 LSAs
- Cost/Metric information is included in these LSAs (unlike Type-2 LSAs but those do serve a different purpose)
- Contain routing prefix/host information for reach-ability purposes.
LSA Type 5 – AS-External LSAs. Type 5 LSAs are also originated by ASBRs and represent external routes from another Autonomous System (or routing protocol) typically done via redistribution. Type-5 LSAs will contain metric/cost information similar to that of Type 3s & 4s, however because this information external from the OSPF routing domain there is some additional information included within this type of LSA.
- External Metric (E-bit) – Designates the external metric of the route. Used for Type-2 External routes, where as Type-1 external routes do not include this information (IE: Set to 0, so the field is included just the value is set to 0)
- Forwarding Address – Specifies where transit traffic should be sent, in some cases this can be (intentionally) set to all 0’s in which case the forwarding address will be that of the Router-ID of the originating router.
- Route Tag – Used to set tagging information of the route itself (typically for mutual redistribution purposes). 32-bit field.
- Remember redistributing static or connected routes also generates Type-5 LSAs, the routes do not always have to originate from another routing protocol.
LSA Type 7 – External LSAs, only found when using NSSA Areas (Not So Stubby Area). So if Type-7 LSAs are only found in NSSAs then how does this reach-ability information make it to other areas? Well the NSSA Border router will translate these Type-7 LSAs to Type-5s for the rest OSPF network/Areas, this is designated by the P-bit / Propagation bit.
Back to studying I go!
CCIE Challenge 1: Manipulating EIGRP Routing
So last week (Well actually months ago at this point) I was helping out one of buddies who is working on his ROUTE exam and he was working through an EIGRP load sharing lab involving the variance command and interface metrics, after I read through the lab and looked at the requirements I came up with a completely different way to complete lab then what was expected. So I figured I would alter the lab and post it up here:
Objectives:
- You want R1 to load share over links Serial0/0 and Serial0/1 that connect to R2 to reach the 3.3.3.3 /32 prefix on R3.
Rules:
- You cannot make any configuration changes to R1.
- You cannot create any static routes.
- You cannot create any additional interfaces.
- You cannot configure any additional routing protocols. (IE: OSPF, BGP, etc)
- You cannot change any AS types.
- You cannot change which EIGRP ‘k’ values are being used.
- You cannot change any of the metrics on the existing interfaces.
- The solution must involve EIGRP.
You can download the starting configurations here:
There is also a GNS3 .Net file included in there as well.
Have Fun!
Onward to CCIE!!
Well, I’ve decided to go down the path and become a CCIE! After all I have my CCNP, CCIP, & CCDP I’ve really only got one more level to go to Expert! So while I am still building my lab, I only need a few more routers, a bunch of WICs, and even more cables I have enough to keep studying and moving forward.
So I’ll be trying to get out even more blog posts covering various topics, or whatever topics I stumble upon while tackling the CCIE (and I’m sure their will be a lot of them)
So here goes nothing! (and I’m sure I’ll be saying that 6+ months later when I’m still studying for this)
Configuring a SPAN session.
A SPAN session is a way for you to have the traffic that is transmitted and/or received from one port or VLAN and have it forwarded out another port for analysis purposes. It’s very easily configured by a few small statements and the only thing you have to decide on is which port you want to monitor, the traffic flow you want to see from that port (egress, ingress, or both) and the destination port you want the traffic sent to. (See the configuration below)
Note: For this local SPAN session both the source port and destination port must be on the same switch. RSPAN allows SPAN sessions across remote switches, but I will not be covering RSPAN in this post.
Their isn’t much to consider concerning the source port since it will not be effected at all, the destination port however is treated a bit differently. First off the destination port will be put in a “Monitor” mode, meaning traffic received on this port will be dropped. Only traffic from the source port will be transmitted out of the destination port by the switch that’s it.
You can issue the sh monitor session # command to see if their are any active SPAN sessions on the switch, or if you want to see the details of a configured SPAN session. The source port (fa0/1), traffic flow (both), destination port (fa0/2), and the encapsulation, are all shown in the command. To close down a SPAN session simply issue the no monitor session # command.
Now your next question might be, what are you going to use this for or why are you going analyze the traffic? Well, if the station at the destination port is running Wireshark, it’s a real easy way to get a glimpse at the traffic traversing your network. From their you can look through the data and see if anything sticks out. Alternatively you can have a SPAN session provide data to a IDS/IPS system so it can monitor your network for any abnormalities.
CCIE or Null! 