Archive for May 2015
Let’s Review: EIGRP Named Mode
My next stop on my CCIE: R/S Written review. EIGRP, the big change here is EIGRP Named Mode it’s the same EIGRP with a new shiny cover. So , let’s jump in.
To start the new named mode configuration we need to define the ‘named instance’ compared to defining the autonomous system out of the gate.
Now, we are dropped into router configuration mode, with a new set of configuration options
From this configuration mode, we can turn on/off the EIGRP instance, configure the address family instance and service family instance. However, from this top layer I do not see the option to configure the advertised prefixes or alter metric information. So lets dive a bit deeper and look at the address family configuration. (If you have done anything with MP-BGP, you’ll know where this is going:
Looking through the address family configuration options, we start seeing options that we are familiar with. First off we decide if this will be IPv4 or IPv6, then we can decide on the autonomous system, whether this is a unicast or multicast address-family, and the last cool thing VRF specific details!
Once we define the IP version and AS #, we get dropped if in a new configuration mode, where we get into some more of the nuts and bolts:
Notice from here, we can define what interfaces participate in this EIGRP Address Family, along with some metric information and we can define specific neighbors (POP QUIZ: How does statically defining neighbors affect the behavior of EIGRP?)
Some of these configurations take us deeper down the configuration-mode rabbit hole, for example configuring the af-interface goes down another level. In this next configuration mode we can define interface specific options such as summary routes, BFD, timer intervals, and much more:
What about route filtering and redistribution, so far we haven’t seen a way to do that yet. This is where the topology base command comes in:
Now, the picture is becoming complete. From this topology configuration mode we can perform some route-filtering, redistribution, and even apply offset-lists to further manipulate routing metrics.
So the configuration is quite different than the old method but at least now it is all contained in one spot in a more hierarchical model.
Another, fun fact. You can migrate the old EIGRP syntax to the new named mode configuration with the following command: eigrp upgrade-cli
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!
Configuration management 101
Configuration management, without a doubt this is probably one of those things we all do, but to what end do we perform configuration management though? Usually configuration begins and sometimes ends with backing up and storing those configuration files but how much further can or should we go with configuration?
- Backing and storing configuration files – As mentioned before, this is step one. Keeping a copy of your device configuration is one the easiest and quickest ways to restore a device back into service after a physical failure.
That one task, as simple as it sounds it the heart of good configuration management. From that original point we gain the ability to perform many other tasks:
- Configuration comparison – Having the ability to compare two of your previously saved configuration can prove to be an invaluable resource. Let’s say you have dozens or hundreds of remote “cookie-cutter” devices out there and you have a single device acting up, comparing the configuration to a known good configuration can save you much troubleshooting time. Especially when you consider many configuration managers are convenient enough to highlight discrepancies making possible errors stand out like a sore thumb.
- Configuration / Version archival – This point follows suit with comparing configurations, because in most cases you may want to compare configurations from the same device that are from different points in time. Making it easy, to pin-point any recent configurations that could be causing the issue at hand.
- Reacting to configuration changes – Changes are a way a life, if nothing is changing then something is wrong, the tougher part is dealing with a way to manage those changes:
- How do you know when a change occurs? – Many configuration managers will re-act to a device generated syslog or SNMP trap, do you have this configured, are you made aware of changes?
- What do you do when a change occurs? – When this mysterious change occurs how do you re-act, do you acknowledge some type of alert or review some daily/weekly report, perhaps there are some checks and balances to ensure the altered configuration has been backed up after the change or to verify that the change was committed to memory?
- Can you correlate network events with changes? – Do you have any capability of correlating network faults with configuration changes? There are definitely a few of those ‘eye in the sky’ type NMS platforms that are capable of linking device level events to any correlating configuration events on that device. Now, if only we can get a more abstract ability to monitor device groups holistically linking events. In my opinion event correlation exist to some degree with many NMS products, but there is definitely a lot of room for improvement.
- Do you enforce a baseline or set configuration standard? – This one in my mind, is where many tools have lack-luster performance, when you find yourself in a situation with many nodes, you definitely want some ‘checks and balances’ out there. How upsetting is it when you find out that the issue you have been troubleshooting is all because a recent firewall change or routing policy change never got deployed to a particular device? If you can enforce some type of configuration ‘compliance’ or ‘baseline’ I guarantee you, that you solve many headaches before they occur.
- Software Management – While, this might seem outside of the scope of configuration management keeping your software versions in sync can be quite important and detrimental for keeping configurations in Sync
- Software versions – Different software versions may implement different command syntax, this in itself can make configuration & troubleshooting tedious in itself. Different versions may also suffer from different software bugs/caveats into your environment.
- Software licenses – Depending on the vendor and the device, if the incorrect license is applied or the incorrect software train is installed on the device some features may not even be configurable. Nothing is more upsetting then when you are trying to configure a device and you find out a simple license (non-technical) issue is the root cause.
So, there we have some groundwork for configuration management do you have other considerations in regards to configuration management?
Not all certificate formats are created equal.
One of my favorite questions: ‘What format do you want that certificate in?
Which then forces me to think and try and remember what was so special and different about all the certificate formats again?
We’ll start with:
- PEM – Privacy Enhanced Mail
- Certificate represented in text format. In a Hex/ASCII format BASE64 encoded
- DER Encoded.
- Key – Private Key
- This format is used for storing private keys.
- Found in the .key extension.
- PKCS#7
- Defined in RFC 2315
- More than a single certificate can be bundled in this format.
- Certificate chains can be included in this format.
- Typically found with .p7b, or p7c extensions.
- PKCS#12
- More than a single certificate can be bundled in this format.
- With this format both the public and private key can be exported/combined.
- A key difference between PKCS#12 & PKCS#7
- Even certificate chains can be combined into a single file.
- Typically found with .p12 or .pfx extensions
Just a quick run through of the a few certificate types.
CCIE or Null! 