What happens when you combine the old celebrity deathmatch meets Cisco networking? Well, you get Engineering Deathmatch! Two engineers enter the console and only one gets out! (You’ve seen Tron right!!?)
Well….. it’s almost that dramatic. Have you ever wanted to go head to head against a fellow engineer, put your wits to the test, and see who can fix the network quicker? Engineering Deathmatch let’s you do just that. I went up against Daniel Dib and while I did not arise victorious it was a still a very fun scenario! Major kudos and props to a good friend of mine Jon Major (pun intended) for building out the crazy scenario that had both Dan and myself stumped for quite some time. It certainly wasn’t your typical network mis-configuration.
I really do recommend this deathmatch to anyone looking for a good challenge, regardless of your level (CCNA/CCNP/CCIE) or your networking interest (Collaboration/RouteSwitch/DevOps) there could be a deathmatch with your name on it! Especially if you got a good co-worker, friend, or study buddy who doesn’t mind some friendly competition.
I know I’ve been quiet for a bit lately, but now that I’ve gotten a few things in order I’m coming back!
(Now, to tackle all those drafts that have been piling up)
Till next time, happy hunting.. I mean labbing!
Just kind of a shout-out to those running ASA’s, be careful when you upgrade to v9.4+ or v9.5+, and beyond.
In v9.4+ when the ASA attempts to negotiate an SSL connection it will attempt to use an ECDSA Cipher as part of TLS v1.2 if the client supports Elliptic Curve ciphers. In this situation the ASA will present it’s self-signed certificate regardless of it’s configuration.
You’ve got 2x Options to fix this:
- Use an ECDSA Certificate
- Disabled ECDSA Cipher with the following command: (Might want to cut-out some of those weaker ciphers)
ssl cipher tlsv1.2 custom “AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA:RC4-SHA:RC4-MD5”
Funny thing is, this is mentioned in the v9.4 release notes. However, it is not mentioned in the v9.5 release notes, so if you were to say upgrade from v9.2 or v9.3 and hop directly to v9.5 (A fully supported upgrade path) this could be something that creeps up on you. After all why you read through the release notes of release you are completely skipping!
Direct Link to the bug can be found here.
You can easily verify this by capturing the SSL Negotiation and checking the Client Hello for TLSv1.2 and EC Ciphers:
Of course the Browser Certificate error will be a dead giveaway but sometimes it’s nice to check.
Do keep in mind though, in order to be affected by this you must be doing the following:
- SSL Services running the ASA
- Running v9.4 or beyond
- Running the default SSL Ciphers for TLSv1.2
- Be running an RSA only certificate for SSL negotiation.
Happy hunting, I mean Labbing!
Hard to believe I have been blogging for 5 years! If I didn’t have a record of it I probably wouldn’t believe it!
Last year saw another 30 new blogs posts published, and that doesn’t count my 4 posts for the SolarWinds Thwack Ambassador program or my blog post or two for the Cisco Champion program! And here I thought I’ve been slacking on my blog posts, but I still got over 30 different posts published out there on the web last year! In the last year I am ecstatic to say this blog is seeing around 18k+ visitors a month!
Some of the top posts for 2015. (It’s the recent overhaul to WordPress I can’t see my overall ‘Top’ Stats)
- CCIE: Data Center Study Links Page
- Routing on a Cisco 2960 Catalyst Switch
- Verifying IPSec Tunnels
- IKE Main Mode, Aggressive Mode, & Phase 2
- Understanding a Wi-Fi Connection
Well, here is to another year! Like all my previous years I’ve got a handful of posts in my drafts pile getting ready to get published! SourceFire, More Wireshark Tid-bits, Wireless, and more Route/Switch topics!
Since Cisco announced EoX for both it’s traditional IPS and it’s CX-Modules it’s been time to start looking at the new SourceFire modules, however that can be quite an undertaking since SourceFire is a completely different beast from its predecessors. Which raises the question where do you start to begin getting familiar with this new system.
I’ve found a good place to start is with a Cisco Live Sessions BRKSEC-2018 (Link below), the reason I like this session is the fact it covers many of the initial questions for implementing or migrating to the new platforms:
- How is the new platform managed & maintained. Being able to successfully manage a platform is one of the most important aspects of deploying a technology. After you verify that technology will meet your deployment requirements of course.
- What is the best way to migrate from the traditional IPS or CX platforms. whether or not you using a software module in the 5500-X ASA Firewalls, hardware modules in the 5585-X platforms, or if you have been using dedicated IPS appliances.
- The new licensing structure. Sometimes we get lost in the technical details, however the licensing details can take our deployment and stop it dead in its tracks.
- How the new policies work. Next-Gen IPS is a much needed and drastic change from its predecessor, understanding the new capabilities and how to configure these features are detrimental to a successful and secure deployment.
Outside of the deployment considerations, this session skims the surface of a technical deep dive. However, There are a handful of other Cisco Live Sessions, (links are below) that go more in depth into other aspects of SourceFire and FireSight’s capabilities.
The next best stop is going to be reviewing the configuration guide for FireSIGHT, which is the management platform for the SourceFire platforms. Like many other configuration guides you are looking down a few hundred intimidating pages. So it might be best to start off with the topics you need and then expand.
There are also some great Configuration Examples out on Cisco.com that cover topics from the initial setup and install, URL Filtering, Active Directory Integration and required permissions, to some SNORT examples.
Small collection of SourceFire Links:
A few CiscoLive365 sessions:
- BRKSEC-2018: Tips & Tricks for Successful Migration to FirePOWER Solutions
- BRKSEC-1030: Introduction to SourceFire NGIPS
- BRKSEC-2028: Deploying Next Generation with ASA & FirePower Services
- BRKSEC-2139: Advanced Malware Protection
- BRKSEC-3034: FireSight Network Security Analytics
- BRKSEC-3055: Troubleshooting Cisco with FirePOWER Services
- BRKSEC-3126: Advanced Configuration & Tuning FirePOWER
With Cisco Live 2015 literally right around the corner, now is the perfect time to grab a few last minute items!
- Portable chargers – The days a long, much longer than you expect and let’s face it smartphone batteries don’t last as long as we would like. While there are charging stations at CLUS it’s tough to be without your phone. I highly recommend grabbing a portable charger to keep in your pocket allowing you to keep you phone charged throughout the whole day. I’ll be carrying a couple of them with me, after all you can’t go without a phone!
- Pedometer – The convention center is huge! Without realizing it you can easily find yourself walking a few miles extra each day. It can be fun seeing how much you actually walked over the entire day. You don’t necessarily need a fitbit you can easily get away with a smartphone app. (Another reason to get that portable charger!)
- Twitter – There is a lot going on between important announcements and social get-together’s the hashtag #CLUS will be flying by, keeping you in the know!
- Cisco Events App – Yet another reason to keep the smartphone charged! (I think I see a pattern forming here) The Cisco Events App is an easy way to your schedule accessible in the palm of your hand. Along with a host of useful features such as a map of the convention center, session presentations, speaker information, and much more!
Just a few quick before the conference begins, see you there!
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
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!