Put it on your calendar.  Cisco Live US is June 25 - 29, 2017, in Las Vegas.  This is the largest conference I go to every year, and it’s the highlight of my professional year.  I’ve been going for a few years now and enjoy it for the content and camaraderie.  What are we doing this year?

We’ll fly in on Friday again and do something.  No idea what, but I imagine we’ll throw out an invitation for dinner to the public and meet somewhere.  If you’re going to be in town, let me know, and we’ll meet up.

Check out this advisory from Cisco that came out a couple days ago.  You need to read it and act on it immediately!  I’ll summarize for you : Thanks to a faulty clock signal component, certain Cisco devices will stop functioning after about 18 months and become really expensive bricks!  Reading through it, you’ll see phrases like “we expect product failures” and “is not recoverable.”  Seriously, what the hell? This really warms the heart.

Full disclosure : I was lucky to be among a group of networking influencers invited to Silicon Valley to visit some networking companies and see what they were offering to the market.  I was flown out and given accommodations at the expense of Gestalt IT - the company that organized the event.  I was given some swag by each company, but I was never paid to write a positive review on the product.  Heck, I’m not even expected to write at all.

I wrote this post during Cisco Live and said “I’ll just give it a once-over tonight and publish it.”  That was something like 6 weeks ago now. What a loser I am.

---

Yes, really. QoS has actually gotten some attention this year. After how many years of living in the dark and being feared by junior and senior engineers alike, we’re seeing some really cool technologies coming out for it.

It seems that Cisco Live is about the only thing I blog about in the last…well, few years.  At least I’m still writing, even if it is twice a year.  :)

Here’s a summary about Cisco Live for those who live in a dark hole.  It’s July 10 - 14, 2016, in Las Vegas.  If you do anything with Cisco, you should go.  If you do anything with technology that isn’t Cisco, you should go.  Bring your significant other.  There’s plenty to do for everyone.  Anyway, on to the details for this year’s show.

You should know by now that I always find something to complain about.  Is that a bad thing?  Probably.  Does it help improve things?  Absolutely!

Again, I love going to Cisco Live every year.  Without question, it’s my favorite event of the year.  It’s a great event with great people and great things to do.  With that said, let’s look at what could have been a bit better this year.

Another year, another Cisco Live.  Boy, was it a good one.  San Diego is a great city, and convention center there is plenty big to take care of all 25k attendees.  On top of that, the city itself is equipped to handle groups of 40 roaming the streets looking for food and entertainment.

This year’s event had the usual stuff that everyone talks about - breakout session, keynotes, exams, etc. - but Cisco stepped outside of technology this year by helping others.

I passed the ROUTE exam a few days/weeks/months/something ago and decided to pursue certifications of another sort for a while. The wife and I are trying our best to help the community through our ham radio training, so I decided to go down that path a bit further. One thing I was interested in doing is to do EmComm during declared emergencies. That meant I had to take two FEMA courses online to be allowed in the EOC. I thought they would be terribly boring, but I found them to be quite familiar.

There are three ways to manipulate the interface cost in OSPF.  One is very direct, one changes the presentation of the interface, and the other changes the calculations for every interface.

Set the cost of the interface directly - Just give it the number you want.  Easy.  This is the number OSPF will use in the SPF calculations without doing any math on the interface.

R1(config-if)#ip ospf cost 8482

Set the bandwidth of the interface - The formula that OSPF uses to calculate interface cost is pretty easy to remember - (reference bandwidth) / (interface bandwidth).  Changing the interface bandwidth will obviously change the result of the calculation.  The same caveat for EIGRP route manipulation holds true here; if you change the bandwidth of the interface, you may affect other things like QoS…or EIGRP, now that I mention it.

When you configure OSPF network statements, IOS orders them most-specific to least-specific then does a top-to-bottom match of the interfaces. It doesn’t matter which order you put them in, the configuration will always be ordered with the longest prefix matches first.  Lab time!

I have router R1 with these interfaces.

R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.0.0.1        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Loopback100                10.0.101.1      YES manual up                    up
Loopback200                10.2.101.1      YES manual up                    up

Let’s add the OSPF configuration where 10.0.0.0/8 is in area 2 then check what OSPF thinks is happening.