Difficult Concepts for Newbies

Applying filtering/ interpreting a packet capture on the fly and keeping the source and destination addressing straight.

Its easy when you're whiteboarding it or doing it in a scheduled window. Its not so easy to remember when you're filtering specific ports or IP addresses because "it needed to be done 5 minutes ago".

I always kept it straight by associating source with the word from, and destination with the word to.

Easy concept, but keeping it straight with no sleep at 3AM on a conference call is not.

Hey Jeremy, very interesting thoughts. Just to add to your feedback collection, some 12 years ago, all I could wait to do was getting on the stick and operating IOS. I was more concerned with knowing how to nail up BGP adjacencies then being able to differentiate L2-L4 headers. I would have saved myself a few cycles a couple years down the road if I had pulled on the reigns a bit.

That said your point on relevant vs. irrelevant is good. I like the questions, RIB, FIB, LFIB all fundamentals of control and data plane packet processing. Those concepts will outlast us all, so well worth a few months of focused study.

Respect,
-Brent

What networking concept do you wish you could go back in time and explain to your newbie self?

VPN

For years: oooo you can get stuff from my domain, oooo big deal, you can do that with FTP!

It wasn't until the boss said "So, can the server thingie connect to {branch office}?" that the light finally came on.

How to use/read packet captures. It's incredibly useful to be able to look at a packet capture and realize(for instance) that you have thousands of fragmented packets going across a GRE+IPsec tunnel and maybe you should adjust the MTU size(or use "tunnel path-mtu-discovery") or being able to prove that an issue getting blamed on the network is actually being caused by a server denying access to the user...or the thousands of other ways packet captures can help pinpoint the problem.

My second choice would be the same as yours...the various stages of negotiation while creating an IPSec tunnel, and what the end devices are supposed to be sending/looking for at that stage can definitely save you a lot of time and headaches if you know them.

For other people...I really wish I could pound the importance and use of the OSI model into my Airmen's heads while troubleshooting. I just have to shake my head every time I see one of them start at layer 3 without verifying layers 1&2. 9 times out of 10 it's a physical issue.

My vote would be recursive routing issues with GRE tunnels.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml

http://blog.initialdraft.com/archives/720/

Eigrp delay - using delay manipulation as a best practice to influence metric as bandwidth command is used for QoS policies and could cause issues if you manipulate the bandwidth statement.

Cisco router config where the network command does not mean +network+ will the routing protocol run on, but rather what +interface+ it will run on.

e.g.
router ospf 1
net 10.0.0.0 0.0.0.255

Will turn on ospf routing process for the following interfaces:

int lo 1
ip address 10.0.0.1 255.255.255.248
int lo 2
ip address 10.0.0.9 255.255.255.248
int lo 3
ip address 10.0.0.129 255.255.255.128

Also

router ospf 1
net 10.0.0.1 0.0.0.0

Will tunr on the OSPF routing process for:

int lo 1
ip address 10.0.0.1 255.255.255.0

For me it was MPLS. I knew how to use it and how to configure it, but it was years before I actually grasped it well.

Also, Layer 3 Switching vs Switching/Routing. It's not a difficult concept once it is explained. It just seemed to be so hard to find anyone who actually knew and could/would explain it.

What takes a while to get to grips with is the difference between physical/L2 and logical topology in a network. Without this understanding it can make visualising networks very difficult.

This problem is exacerbated by network diagrams that are neither physical or logical but a Frankenstein mix of the two!

I never had issue with technical concepts or mechanisms. It has always been clear (I probably had only good teachers :-) )

But what I wish I had learned before is that, without a strong argumentation and fighting, most executives (directors and project leaders) like the quick and dirty solution instead of a resilient, well-planed one.

I'd go back and explain the politics in IT and the importance of strong IT leadership. For example, many times the IT team may have several methods to resolve an issue or accomodate a request, but I have found that many of those solutions should not be recommended because as someone else mentioned, the cheapest and/or fastest is often the one chosen by business management.

I wish I had learned earlier on that it is up to the technical team leadership to inform the business decision makers of their options, AFTER filtering the less desirable ones and to hold fast to their recommendations. I would have saved myself countless nights and weekends fixing issues caused by business decision to go with the cheapest/fastest solution.

This is a great post, and one I have thought about a lot.

1) The difference between switching and a switch, and routing and a router. The fact the routers do switching, and switches do routing is pretty crazy as a new network engineer.

2) The difference between the internet and the world wide web. You surf the web. Surfing the internet would be like trace-routing or jumping from AS to AS. And that as a network engineer you are doing so so much more than giving some computer somewhere just access to the internet/web.

IPSEC just always seems much more complicated than needed.

I learned BGP first, I had a harder time understanding protocols like OSPF because of it. I've read that learning these two in reverse order isn't easier either.

Somehow people get a mental model of one and which makes it harder to learn the other.

And DNSSEC isn't particularly complicated if you already understand encryption, but deploying DNSSEC scares me because of the failure modes (there is mostly just one failure mode: complete failure).

First-- Hello Jeremy. I work for a cisco partner 2 hours east of you in Wilmington, NC. All my engineers read your site! Your flashcards helped me pass my CCNP last year, working on my CCIE R&S now.. will lab it up at RTP end of year.

Topics difficult for me to get at first:

VLANs (of all things I find so simple now) OSPF different types Using Tunnel interfaces - VTIs or GRE instead of crypto maps

Stuff i'm struggling with now (taking the CCIE written next month) Multicast! MPLS IPv6 (basically everything I never use on the job)

Hi,
Don't read this... it is long and boring :)

I'm CCSI and I began my studies as a "Cisco Networking Academy Student" +-10years ago.
Truth is I self-studied almost all concepts... Things that was most hard to learn by self are easier to catch if you know the background. And now when I teach, more then my students, I realize if you introduce a problem and think about possible solutions, technologies are just more precise in definition then common sense.

From my beginning i remember
STP, then
Frame-relay, then
MPLS and
IPSec
were hard to learn (not mentioning DUAL, because I was not thinking about it too much over noFS=>send Query :D). Now I realize that technology was not a problem, but
- realize background (historical),
- it is more about knowing what the problem IS, and how to solve IT (STP, Frame-relay), or just about
- splitting a problem to parts (problems) and solve them one by one (MPLS, IPsec)
(DUAL was little more complicated, after few iteration of not caching it and lacking more useful information, i had to go into original Garcia-Lunes-Aceves paper to finally understand)

Problem is that networking technologies are more and more compound (not complicated, but made of more and more pieces of small things). For example IPv6 compared to IPv4...Many people think that it is just a new header... ok it is... but if you try to understand IPv6 this way, it is like seeing a wheel(IPv4), and think that a car is just more complicated wheel, but it is not... a car is bunch of many technologies, easy study one by one (evolution of car) but impossible to compare pure IPv4 and bunch of thinks in IPv6. So going into new technology is more and more demanding. Let take multicast, i studied that problem splitting it (how to send, how to receive, how to route...). and now it is in IPv6 basics... so going into the same detail level just to understand a portion of IPv6 is ...

1.Interaction with the end-user (since no school ever taught me that)
2.NAT; so many confusing terminologies (static identity, dynamic identity, outside nat, inside nat)
3.Multicast (Never used it)
4.OSPF on a frame-relay network

All i can remember for now

The politics of it; Re:
"I'd go back and explain the politics in IT and the importance of strong IT leadership. For example, many times the IT team may have several methods to resolve an issue or accomodate a request, but I have found that many of those solutions should not be recommended because as someone else mentioned, the cheapest and/or fastest is often the one chosen by business management"

Except that also this does not work long term - you and your team become the enemy - since your are deemed a power center, that has all the answers that seem to cost more.
In my last job i came in when they were dismantling a group of entrenched architects.
the politics - the bad blood -toxic - before long we all left - with this phrase in my head - explain it to me like in Ben and Jerry and all i only is need good enough.

This is absolutely right, that's why i decided to make a campaign after 2 and a half years of networking and i called it "Back to Basics". I decided to do several things that makes me understand the concept more than the operation of of protocols and networking

1. Read the first RFCs for TCP/IP and learn the evolution of the network
2. READ RFCs first then read Vendors implementation. (Refer to point 1)
3. Use packet dissection tools like Wireshark for every packet that passes by ( very time consuming, but very rewarding )
4. Listen to people like Ivan pepelnjak and Greg Ferro podcasts and video casts and follow blogs like yours ;)
5. Document everything that I tend to forget about concepts and even operations in a Blog, it makes you obligated to understand so that you can type it out on the Internet

Few on top of my mind are :

1) Various WAN types such as EoSDH , STM1 , Channelized E1/T1 , POS , DWDM etc . Over period of time you start getting better understanding of these things.

2) IPSec...ofcourse.

3) UNIX... :-(