30 Random Networking and Career Tips

Packetfactory.
info
Networking moments, tips and ideas.
30 random networking and career tips for

engineers.
By Oleg Tikhonov
Foreword
All my life I’ve been using other people’s products to gain my knowledge and skills, train myself
and become a professional. I am not talking about my professors in the University or numerous
books I bought and read. I am talking about community and its role: forum, IRC conversations, IM
sessions, tutorials, self-study guides and so on. It was people who dedicated their spare time to
create information which I used to get my answers.
Years later I decided to give back. I have launched PacketFactory.info recently as a place where I
could put my own findings about data networks, routing protocols, switching and so on for other
people. Instead of losing this information in IM sessions with my colleagues and friends I made a
rule to share this information with everyone else and make it publicly available.
This is a collection of 30 random articles bound together for easy reading or making a hard copy.
They either help you to refresh some tricky aspects of routing and switching on Cisco devices or
inspire you to think about your career and the future. Read it yourself and share it with your
friends because this little book is free of charge.
I hope you will enjoy reading it!
Sincerely,
Oleg Tikhonov
oitikhonov@gmail.com
PacketFactory.info - 30 random networking and career tips. © 2011 by Oleg Tikhonov Page 2
All brand names and products are Registered Trademarks of their respective Companies.
Table of Contents
My feedback on books ................................................................................................................................. 4

One more way to group routing protocols ................................................................................................... 5
There is only one best path in BGP ............................................................................................................... 6
Static routes and ARP ................................................................................................................................... 8
Two types of EIGRP ...................................................................................................................................... 9
BGP Next Hop 0.0.0.0 ................................................................................................................................. 11
Cisco BGP Weight ....................................................................................................................................... 13
BGP LOCAL_PREF by Cisco .......................................................................................................................... 14
Disable exec timeouts ................................................................................................................................ 15
How to get rid of typo pauses .................................................................................................................... 16
Annoying IOS terminal output.................................................................................................................... 17
No bit buckets for defaults ......................................................................................................................... 18
Mad ping tests............................................................................................................................................ 19
BGP RIB failure? ......................................................................................................................................... 20
BGP Multi-Exit Discriminator (MED) in Cisco .............................................................................................. 22
How to safely configure remote devices .................................................................................................... 23
Some tips on how to better start your career ............................................................................................ 24
Why Wireshark can be bad ........................................................................................................................ 26
Why Cisco emulation platform would be a good idea and why it is unlikely to happen............................. 27
Changing running configuration in Cisco .................................................................................................... 29
HSRP explained .......................................................................................................................................... 30
RIP Database .............................................................................................................................................. 32
EIGRP load balancing using “Variance” ...................................................................................................... 34
How Route Servers work at Internet Exchange Points ............................................................................... 36
OSPF and default routes............................................................................................................................. 37
OSPF Virtual Links ...................................................................................................................................... 39
Torrents and NAT ....................................................................................................................................... 40
Make your traceroute tool quick................................................................................................................ 41
How to upgrade IOS ................................................................................................................................... 42
Engineering career and rapid change of technology................................................................................... 43
My feedback on books
It’s a well-known fact that our professional success almost directly depends on our knowledge and
experience. Here I’m going to provide some feedback on books I’ve read recently.
To put it simple – read the best. Even if you’re preparing for some exam on XYZ technology pick the
one people label “Bible” rather than some special or “recommended” for this particular event. You
will have to read them anyone – so why bother reading other books and waste your time?
Let me through in few examples. I should also mention that I’m not going to tell anything about
other topic aside routing this time mainly because routing is the core. Second of all, other
technologies (e.g. VoIP, security) depend on marketing too much, technologies come and go.
Routing stays.
Routing
Start with these to get some solid foundation:
• Routing TCP/IP, Volume 1 (2nd Edition) by Jeff Doyle, Jennifer Carroll

• Routing TCP/IP, Volume II (CCIE Professional Development) by Jeff Doyle, Jennifer DeHaven
Carroll
Then deeply dig into each technology reading these:
• TCP/IP Illustrated, Vol. 1: The Protocols by W. Richard Stevens for TCP

• Internet Routing Architectures (2nd Edition) by Sam Halabi for BGP
• OSPF: Anatomy of an Internet Routing Protocol by John T. Moy for OSPF
• OSPF and IS-IS: Choosing an IGP for Large-Scale Networks by Jeff Doyle for OSPF and IS-IS
I can’t stress this enough – these books are superb. You will read them, read them again and you
will keep coming back for years. Once you get through this list you will understand me. You don’t
need any of useless money-greedy video lessons where some nervous guy screams and shouts
stupid jokes for two hours just to tell you how ARP protocol works. You don’t need any of books by
“experts” who managed to write 20 or more volumes crammed with conceptual mistakes and
errors (the one who wrote 25 books is clearly a con, not an expert).
I hope you got my point.
One more way to group routing protocols
We all know that routing protocols are either IGP or EGP, link-state, distance vector, path vector,
etc.
I am going to remind you about one more way to logically group them:
• with periodic updates

• without periodic updates
This can help you to understand and memorize why OSPFv2 has MaxAge (up to 1 hour) timer or
why RIP routes also can be timed out so that router will forget them. If you think about it, these
timers can only be useful if there is some way resets them – like periodic updates. In contrast, BGP
and EIGRP rely on opposite peers/neighbors to either die and take all their routes with them or
send an update to announce death of certain routes.
There is only one best path in BGP
Single path
During labs it’s good to remember the fact that, naturally, BGP does not have equal paths. BGP
Best Path Algorithm always has a way to break any tie. It is possible to balance across more than
one link in some implementations but only the best route will be announced to internal or external
peers anyway.
“Split Horizon”
Strictly speaking, split horizon is a wrong term in BGP context but it is a good way to memorize 2
facts:
1. Most BGP implementations will not advertise a path for some prefix to a peer if the best path
for this particular prefix was received from that peer.
2. iBGP learnt routes are never sent to other iBGP peers. As NEXT_HOP and AS_PATH are always
same inside one AS, all iBGP peers must be full meshed to avoid loops or suboptimal routing.
Next time you play with LOCAL_PREF or prepend AS_PATH keep in mind that some peers will have
several routes for a particular prefix while others will have only one.
Example
You have two border BGP routers connected via iBGP. Both routers peer with dedicated ISP eBGP
peers and receive routing information from ISP:
You tweaked LOCAL_PREF so that only R1 will be used for all outbound traffic.
R2 router will have 2 possible paths per external prefix:
• from its eBGP peer ISP2

• from its iBGP peer R1 (the best route)
R1, however, will have only one path (towards ISP1) as iBGP peer R2 will not send its variant of the
path.
Moreover, R1 will not send external paths back to ISP1.
R2 may send them back to ISP2. These routes will be discarded by ISP2 anyway because AS_PATH
value will contain AS number of ISP which alarms a loop. However, this fact can be useful if you
analyze traffic dumps in Wireshark.
Static routes and ARP
One common mistake people often make is related to Proxy ARP and the way Cisco IOS allows us
to configure static routes.
Here R1 was configured with static default route and someone decided to provide an outgoing
interface instead of next hop address, like this:
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
Though it looks darn same, it behaves differently: every time an interface is provided instead of IP
address, added route is treated as locally connected. It means that each time someone at R1′s LAN
initiates packet exchange with The Internet, R1 tries to forward packet to R2 via its default route
and uses ARP to get the MAC address of packet’s destination because this default route looks like
some universal physically connected LAN which has everyone on board.
This will work if R2 has Proxy ARP enabled (which is default for Cisco). R2 will send ARP Replies in
the name of hosts from networks it knows about. Meanwhile, R1 will have a separate ARP Cache
entry for each destination IP resolving to the very same MAC address of R2′s F1/1.
If R2′s IP address was used, R1 would have only one ARP entry related to R2′s FastEthernet1/1
(next hop for R1).
Two types of EIGRP
Ever wondered why are there 2 types of EIGRP with different Administrative Distances?
This question implies some serious answers. However, I’m going to cover one single fact only. As
almost every contraption in routing it helps to avoid routing loops.
• Internal EIGRP has AD of 90
• External EIGRP has AD of 170
Different AD values help to avoid routing loops when there are 2 routing domains and more than
one redistributing router.
Example
There are to different IGPs running: OSPF and EIGRP. Both R1 and R2 redistribute between these
IGPs.
Now, Rx announces subnet “A” across EIGRP domain so that both R1 and R2 have it in their RIBs
with Administrative Distance of internal EIGRP which is 90. “A” gets redistributed into OSPF
domain as Type5 external route (R1 and R2 act as ASBRs for this domain) so that Ry gets familiar
with “A”. This far everything looks fine.
However, we can have a look from a different angle. R1 gets “A” via EIGRP from Rx, redistributes it
to OSPF and sends out LSU with LSA Type5 for “A” across OSPF domain. R2 gets too. As both R1
and R2 redistribute not only from EIGRP to OSPF but also from OSPF to EIGRP, R2 should try to
redistribute “A” back to EIGRP because it is an average OSPF route. Thankfully this won’t happen
because EIGRP has AD of 90 which is less than OSPF’s 110. OSPF-learnt route for “A” won’t get into
RIB thus it will not be redistributed.
The second scenario is reversed:
Ry announces “B” across OSPF domain, R1 and R2 redistribute it into EIGRP as an external EIGRP
route with AD of 170. If any of the redistributing routers tries to push “B” back to OSPF, it won’t
happen:
AD of OSPF is 110 which is less than external EIGRP’s 170 – none of redistributed variants of “B”
will be in RIBs of R1 or R2 and as we know, due to IGPs internal differences the only source
redistribution system has is RIB.
BGP Next Hop 0.0.0.0
I once stumbled upon the following vogue explanation of show ip bgp output in a book. It is also
present at Cisco.com BGP FAQ:
Q. What does a next hop of 0.0.0.0 mean in the show ip bgp command output?
A. A network in the BGP table with a next hop address of 0.0.0.0 means that the network is locally
originated via redistribution of Interior Gateway Protocol (IGP) into BGP, or via a network or
aggregate command in the BGP configuration.
I think this explanation is not very clear.
Example
First off, here is a fragment of sh ip bgp output which displays a prefix, one route to which is
redistributed from IGP:
* i10.0.0.4/30 172.16.1.13 0 100 0 ?

* 10.0.0.1 30720 0 500 ?
*> 172.16.1.13 2 32768 ?
If we look further:
R2#sh ip bgp 10.0.0.4

BGP routing table entry for 10.0.0.4/30, version 5
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to update-groups:
1 2
Local
172.16.1.13 from 172.16.1.13 (172.16.1.13)
Origin incomplete, metric 0, localpref 100, valid, internal
500
10.0.0.1 from 10.0.0.1 (16.16.16.1)
Origin incomplete, metric 30720, localpref 100, valid, external
Local
172.16.1.13 from 0.0.0.0 (172.16.1.14)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
As we can see, the next hop is actually the one from IGP.
The meaning of 0.0.0.0
0.0.0.0 symbolizes the local device. It makes sense to have 0.0.0.0 as the next hop for aggregates
and routes injected via network command because these routes start their existence in this very
device. It doesn’t however make any sense for routes redistributed from IGP if they were
originated somewhere else in IGP domain.
The key moment here is that redistributed route will have 0.0.0.0 as its next hop if it is local from
IGP perspective (thus, it originated locally). Otherwise, its next hop will be derived from IGP so that
it can be routed.
Cisco BGP Weight
As we all know Cisco has a proprietary addition to BGP Best Path algorithm – Weight attribute
(kind of). It is the first so-called attribute considered (if synchronization is ok and next hop is
accessible). However, it’s not just an extra step for the algorithm, it is also a shortcut for locally
injected routes (which, at some point, are more preferable than iBGP/eBGP ones) to be considered
at the very beginning.
Cisco device assigns a Weight of 32768 for all locally injected routes which is bigger (and better)
than default 0 for all other sources.
This way, local routes are more important than routes with better LOCAL_PREF inside each device,
while usually local preference is considered first.
Here is the part of the best path selection algorithm we’re interested in:
• Prefer highest Weight (Cisco only)
• Prefer highest LOCAL_PREF
• Prefer locally injected path
o tie break:
added via network or redistribute
added via aggregate-address
• Prefer shortest AS_PATH
• etc.
If this fact looks unimportant, you can still find it helpful and use Weight to quickly spot locally
added routes in show ip bgp outpout.
BGP LOCAL_PREF by Cisco
Here is a small note about one BGP glitch in Cisco products. For some weird reason cisco box won’t
show you the default local preference while it’s still there.
R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 10.0.0.1 0 0 500 i
*i 10.0.0.5 0 100 0 500 i
As you can see, there is emptiness for the first route. However, if we dig a bit deeper, LOCAL_PREF
will show up:
R2#show ip bgp 0.0.0.0

BGP routing table entry for 0.0.0.0/0, version 28
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
500
10.0.0.1 from 10.0.0.1 (16.16.16.1)
Origin IGP, metric 0, localpref 100, valid, external, best
500
10.0.0.5 (metric 2) from 172.16.1.13 (172.16.1.13)
Origin IGP, metric 0, localpref 100, valid, internal
The possible reason is that some IOS snippet reads LOCAL_PREF from some structure derived from
received updates but routes learned via eBGP obviously don’t transport LOCAL_PREF in updates.
Disable exec timeouts
There is one more convenient feature of IOS which allows for infinite configuration time on lines if
configured with 0 minutes 0 seconds:
Router1(config)# line con 0 [vty 0 4]

Router1(config-line)# exec-timeout 0 0
Here is the result:
Router1#sh line con 0

<skipped>
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch
never never none not set

Idle Session Disconnect Warning
never
Make sure to apply it to both console and vty lines.
It may not be acceptable in live networks due to security or political issues but it is obviously useful
for labs.
How to get rid of typo pauses
Isn’t it annoying to mistype some command and become stuck, trying to either cram in that tricky
abort key sequence or wait till DNS resolver cools down (which takes a while)?
For example, I’ve tried to save config by using old-school wr command:
R4#rw
Translating “rw”…domain server (255.255.255.255)
(255.255.255.255)
Translating “rw”…domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
R4#
There is an obvious solution – use no ip domain-lookup command to disable DNS lookup:
R4#rw
Translating “rw”
Translating “rw”
% Unknown command or computer name, or unable to find computer address
R4#
*Jan 18 14:05:05.663: %SYS-5-CONFIG_I: Configured from console by console
R4#
Certainly, it’s not appropriate in many production situations but we almost never have excuses not
to use this simple technique in Lab environments.
Annoying IOS terminal output
Alright, this one is quite popular, yet many engineers tend to forget about this useful command
(including myself):
logging synchronous
Being applied to line config (line Console or VTYs) it allows you to keep typing without being
disturbed by those annoying logs, debugs, etc.
Configuration:
Router(config)# line vty 0 4

Router(config-line)# logging synchronous
Every time some output pops up in the middle of the CLI line you’re currently editing, IOS will make
a new line and paste all your work there so that you’ll be able to continue.
No bit buckets for defaults
A mate of mine once stumbled upon one trivial network behavior which has some philosophical
idea behind its simplicity.
We all know that RIB entries which point to Null interface are necessary for each summary or
aggregate route created. He knew about that and got used to it. Once he created a default route in
OSPF and expected it to create the route to Null because 0.0.0.0/0 is ultimately an outstanding
form of aggregation which spans across all address space. Obviously, it didn’t happen and here is
why:
Here we can see border router (BDR) which runs BGP with ISP router to receive default route from
it and announce its own 10.0.0.0/0 prefix which is used throughout the network.
As the bottom cloud suggests, only some part of 10.0.0.0/8 is currently used but in this scenario
10.0.0.0/8 is dedicated to the whole network. This is why BDR has to has 10.0.0.0/8 pointing to
Null0 interface in its RIB – BDR is the only entering point into 10 network, all traffic must be either
routed deeper in the network or dropped (as we know, all packets routed to Null interfaces simply
get dropped).
Let’s suppose that BDR is the only router which runs BGP. In order to receive all Internet-bound
traffic, BDR announces default route to the rest of the network. In this case, it must not have
0.0.0.0/0 route pointing to Null interface because it needs to forward all outgoing traffic to ISP via
another default route: 0.0.0.0/0 pointed to NEXT_HOP of ISP.
Mad ping tests
I bet we all saw some guy desperate to troubleshoot a network with echo requests of increasing
sizes without any idea why. I suppose it is something we sometimes do unconsciously.
Let’s recall the following things:
• MTU
• DF bit of IP
• ICMP payload
• Maximum IP packet size
First of all, we should know if our host machine which we use to initiate ping (echo request) sets
Don’t Fragment bit for IP packets which encapsulate our echo requests. In most cases DF bit is not
set for ICMP and UDP by default. Second of all, MTU size is pretty consistent nowadays (again, in
general networks). Third: Payload for ICMP Reply packet should be exactly the same as in received
Request. And finally: IP packet, due to its header has limits on maximum packet size, it also can’t
address an infinite OFFSET.
So, in most situations you either get a direct error from your host (if you disabled fragmentation)
or simply send some big request and receive some big reply (both get fragmented and
reassembled by IP layer). You did apply some sensible load on the network but in many cases this
doesn’t give you much information. You don’t know where on the network the bottleneck
occurred, was request or reply dropped, etc. If you do – you still can’t measure it accurately since
ICMP packets are often treated with less priority. Besides, large pings may be blocked or filtered by
security mechanisms.
The bottom line
Using large ICMP Request payloads can be meaningful but there should be a clear reason and
understanding of what’s going to happen.
BGP RIB failure?
If you haven’t worked with Cisco implementation of BGP enough you may stumble upon BGP RIB
failure in sh ip bgp output and wonder what it means.
Here is some output:
R7#sh ip bgp
BGP table version is 31, local router ID is 18.18.18.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path

* i0.0.0.0 15.15.15.1 0 100 0 i
*> 0.0.0.0 0 32768 i
r> i88.0.0.0 15.15.15.1 0 100 0 666 i
Now we can try to investigate the matter:
R7#sh ip bgp rib-failure

Network Next Hop RIB-failure RIB-NH Matches
88.0.0.0 15.15.15.1 Higher admin distance n/a
This gives us a hint. Now, if we check RIB we’ll get the source of this anomaly:
R7#sh ip route 88.0.0.0

Routing entry for 88.0.0.0/8
Known via “static”, distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.9
Route metric is 0, traffic share count is 1
As you can see here, the route received from BGP cannot be inserted into RIB because there is a
static route with lower Administrative Distance (1 vs. 20).
Conclusion
In many cases RIB failures don’t indicate any dramatic problems on the network. For example, it
can be your eBGP peer which was configured with network command which hooked up your
transport /30 subnet between BGP peers. However, it might be a good idea to keep an eye on
them using show ip bgp rib-failure command.
BGP Multi-Exit Discriminator (MED) in
Cisco
Multi-Exit Discriminator is a BGP attribute generally used to advise single external AS you peer with
about the best entrance to your own AS. For example, if you have 2 border routers which peer with
2 other routers of AS “X” you can tweak MED to advice “X” to use the 1st router of yours for all
traffic towards your Autonomous System.
As we stated, MED is the best entering point for some particular prefix in AS. The best entering
point is the best path across AS cloud between some border router and some final subnet in terms
of IGP (because IGP is used for routing inside AS in most cases). So, the best border router (the one
peering with other AS via eBGP) in terms of MED is the one which has the shortest IGP path to final
prefix.
In order to use MED, you must configure route-map and advise the router to put IGP metric of
some prefix into MED field of BGP update for this prefix:
route-map set_MED permit 10

set metric-type internal
One tricky moment here is that the word internal means 2 different things in IOS:
R2(config-route-map)#set metric-type ?
external IS-IS external metric
internal IS-IS internal metric or Use IGP metric as the MED for BGP
type-1 OSPF external type 1 metric
type-2 OSPF external type 2 metric
Cisco devices have one more interesting addition to this behavior:
Every time you redistribute IGP routes in BGP, Cisco will put IGP metric in MED automatically.
Here is a snippet from my lab network which OSPF redistribution into BGP:
* i192.168.222.1/32 172.16.1.10 2 100 0?

*> 172.16.1.2 3 32768 ?
As you can see, “2″ and “3″ actually came from OSPF costs.
How to safely configure remote devices
Sometimes we face with the most annoying task – configuration of some router which is infinite
miles away. Unfortunately, Cisco IOS is pretty ancient in terms of flexibility of operations with
config files.
It has however one crucial feature which must be used by every engineer – reload command.
You should know about these 3 arguments:
reload in minutes
reload at time
cancel reload
Before making any changes to running config you must issue any of the first 2 commands to tell the
router to reload in some minutes or reload at precise time without saving the config. After you
alter configuration and check that your box is still accessible, you should cancel reload task you’ve
scheduled by providing cancel reload. If you mess up and loose management connection, your
device will reload as scheduled and you’ll get your console back.
This very simple command will save you heaps of your nerves. You don’t want to know the stories
people got into after changing ACLs or shutting down ports thus cutting themselves out of the box.
Some tips on how to better start your
career
Many of you plan or just started their careers in the industry. I would like to share some of my
thoughts on the matter with you. In fact, I’m not sharing with you; I’m sharing with myself but
young and novice.
The very first thing is this: train yourself to study hard. You may see lots of experienced people in
forums, IRC channels and other communities and feel yourself involved wasting all your time on
those resources. You should, however, remember that those people earned their expertise by
studying hard, not by socializing only. It is ok to sort of polish some questions and technical
oddities but please – invest your time wisely.
Don’t blame your boring entry-level position for all your misfortunes and luck of progress. I learned
this from my modest experience. Believe me, even if you work for a top Cisco Gold Partner System
Integrator most of your self-development will concentrate in few time clusters when you faced a
big chunk of some new technology, read several books to prepare for your exam, etc. 90% of the
time you’ll be doing same old boring crap and won’t learn anything new.
Most of the good engineers I know never rely on their company, their colleagues, friends, etc. They
never loiter and learn nothing in wait for some mythical good big projects to come. They study
constantly. They spend their own time cut from their families. This is the curse of this industry –
you will never succeed if you work 9 till 5.
If you’re young – don’t run after quick money. Plan your technical career 2-3 years ahead and stick
to it (unless you discover that your plan is silly). If you’re 1st line support engineer – you may get
lots of responses to your CV. The more skilled you become the less responses you get. So, don’t be
fooled that you’ll be able to find a job in a week once you become skilled and expensive. Don’t rush
after money and don’t work with silly technologies – you’ll regret it. Personal example: I once went
for some money which looked good back then for me and wasted almost a year working with
Videoconferencing and similar trivial crap until I realized that such a specialization is poor in terms
of growth. I still regret that I was blind and haven’t stayed in a less-paid but more perspective
position in ISP.
And the last one for now – yet the most important – don’t be too geeky, learn how to build your
professional network. Some people realize it pretty late too. The bitter fact of this life is that you’ll
almost never see the best positions in public access. The better some position is (in terms of
money or interest) the more chances that someone will try to hire from his/her social network.
There isn’t anything dirty in this – people simply try to work with someone they know and trust.
Lots of engineers actually migrate from one company into another in flocks – someone becomes
chief engineer and brings his mates from the previous company. They split and unite again many
times. This industry is very small as you’ll see.
Why Wireshark can be bad
Wireshark, tcpdump or IOS-embedded packet sniffer are great learning and troubleshooting
instruments. However, all traffic sniffing tools have, in my opinion, some negative impacts on your
skills and work.
The very first thing which comes into my mind is a habit of bottom-up troubleshooting and
debugging approach packet analyzing tools develop in you. Once you become familiar with under
the hood logic of some technology or protocol, you may tend to sniff traffic as the first step of
nailing problems. Learning and lab experience reinforce this behavior even more.
It is good to know stuff deeply but sniffing is not the best option for every problem.
There are several troubleshooting methodologies which are appropriate for problems of different
features. To utilize the best approach in some particular situation you really have to be familiar
with debugging commands of your vendor. You don’t want to collect traffic dumps too often – it is
almost always faster to type in some commands and nail the bug than to sniff everything and then
compute stuff in your head. Besides, you won’t be able to identify many problems from the dump
only.
This may sound preachy but I’ve seen people whose problem solving efficiency decreased once
they stumbled upon some remote issue in a situation when it was simply impossible to collect
traffic. They didn’t feel comfortable, like smokers without tobacco. Cisco TAC engineers ask you to
provide traffic dump either when other techniques failed or when they don’t have time to work on
your case right away.
I personally try to keep this in mind to gradually become a better engineer, to be able to predict
problems and act by mind, not by habit.
Why Cisco emulation platform would be a
good idea and why it is unlikely to happen
We all like dynamips/dynagen/gns. Some people have started to promote an idea of asking Cisco
to provide us with the official emulation platform for learning and testing purposes. Recent
changes in IOS 15, migration of ISP track to XR and restricting software access via CCO inflate those
talks even more. Here is my 2 cents.
Why emulation is good
Imagine a group of architects building a bridge after reading some books and scratching in
PowerPoint. Imagine several iterations of producing parts of some aircraft by heart just to test if
they will assemble together. Imagine a factory without standards, planning, etc. Such a situation
doesn’t look plausible – it’s not how big and serious things are done in tough segments of our
economy.
However, this is how modern Telco and IT operate. No responsibility, no system approach, nothing.
This is why people laugh at you when you reveal your profession and then call yourself
an engineer.
This industry doesn’t look mature and professional enough. It’s still a geek playground. We don’t
use CAD systems to thoroughly test proposed solutions before selling or deploying them. Software
licenses state that they are ready to get your money but won’t guarantee anything in return.
Integrators do not offer any solid and tested solutions from their portfolio; they sell hope that
everything will be fine. Customers lose money, time and patience, service providers lose man-
hours, engineers lose nerves because they’re obliged to be responsible for solutions they know
nothing about.
We don’t have instruments to prepare good solutions. We can only go there and test it during the
project. The current response by vendors is simple – buy twice as much and build an equivalent
lab.
Vendors consider that provision of emulation platforms is not an option.
Why getting needed instruments it is unlikely to become reality
First of all, it is a technological problem. You can’t build a much cheaper equivalent of something
with same functions. Playing with dynamips is a very good thing but it is not a product you
purchased. If some vendor ships a product similar to dynamips today, people will complain
tomorrow that they’re unable to test this and that. They can’t ship their developing stuff either – I
presume it is buggy semi-hardware kit collection difficult to manage or operate because it’s was
not developed with end users in mind. If they build The Product it will cost heaps but will be
emulation anyway. Cisco, for example, simply has labs for its engineers. It’s dirt cheap for Cisco.
Second of all, I don’t think they care. If you’re a small enterprise – it’s your problem if something
won’t go as planned. If you are an immense government organization, you will buy yourself a lab,
or even two if you need. Problems generate support market.
Third: technological foundation of building a bridge changes slower than things in IT. Space crafts
are more expensive than migration of an office to VoIP. Modeling and testing systems for such
extraordinary things cost more than your networking projects. If your project is that expensive, you
can justify building a lab.
Probably, we should just embrace the fact that in this field everything is messed up and make sure
the client believes in that. Nobody will invest resources just to make it easier for you to pass CCNA.
Changing running configuration in Cisco
Many people mess up stuff when they try to copy some config file into running configuration.
There is one important thing about it in Cisco IOS.
There are two commands which have major difference in their operation:
• copy file running-config

• config replace file
The first command does merge operation. It adds command from file if they are missing in current
running configuration or alter those commands overwriting the ones in current running config with
the ones from provided file. The most common mistake is that this command will not delete any
commands from running config if they’re not present in provided file.
If you’re after complete replacement of running configuration, use the second command instead. It
will wipe the running config and put the one from its argument.
HSRP explained
I’ve noticed that HSRP protocol is usually described from operational point of view only. Here I am
going to give a basic example of HSRP from design angle.
HSRP Basics
Hot Standby Router Protocol is a next hop or default gateway redundancy instrument. Even though
it is described in RFC it’s still a Cisco proprietary thing because RFC 2281 is informational.
Participating networking devices communicate with each other and provide a virtual IP and MAC
addresses for servers or workstations, elect the Active and Standby roles. If Active one dies,
Standby (the router with next-highest priority) will start answering ARP requests for virtual IP. You
may google more details.
HSRP Design
Here is an example of how it may be implemented on the network:
We have a L2 access layer switches (SW1…SWn, for example a switch per floor) which connect to
both core devices via 802.1q trunks for redundancy. L3 Core switches (CS1, CS2) terminate VLANs
on SVI ports. One subnet per VLAN is assigned (192.168.23.0/24 for VLAN 23). Both core switches
will have SVI interfaces for VLAN 23 configured with their own IP addresses in 192.168.23.0/24
subnet plus HSRP group will be configured on those SVI interfaces with its own IP address from the
subnet.
• SVI 23 on CS1 – 192.168.23.1

• SVI 23 on CS1 – 192.168.23.2
• HSRP group on both SVIs – 192.168.23.3
Sample config for CS1:
interface Vlan23
ip address 192.168.23.1 255.255.255.0
standby 10 ip 192.168.23.3
standby 10 priority 200
standby 10 preempt
standby 10 track 1 decrement 100
I hope this may help to grasp HSRP implementations for those who struggle.
RIP Database
IP has a special route database to keep all received updates and uses this database to send
outbound updates as well. However, RIP differs from other IGP protocols in a way that it doesn’t
keep all topology information. RIP processes inbound updates to decide if they should go into
route database.
An inbound update will be dropped and won’t get into RIP table if:
• It was filtered by some inbound filtering

• There is a better RIP route for this prefix (less hops)
• There is a route in RIB with better Administrative Distance
As was stated above, RIP uses this database to generate outbound updates. It implicates that if
some route hasn’t reached the database it will not be sent out. This is all simple and logical but
let’s have a closer look on the third drop reason:
Both RIP and EIGRP protocols are configured on some routers (nobody knows why, maybe there is
some IGP migration in process).
R3 has 15.0.0.0/8 prefix in its RIP table:
R3#sh ip rip database 15.0.0.0 255.0.0.0

15.0.0.0/8 directly connected, Loopback1
R3 shares it with R2:
R2#debug ip rip
*Jan 28 22:16:37.827: RIP: received v1 update from R3 on FastEthernet1/0
*Jan 28 22:16:37.827: 15.0.0.0 in 1 hops
However, R2 does not put this route into its RIP Database because it also receives an EIGRP update
for the same prefix and EIGRP has better AD than RIP (90 vs. 120):
R2#sh ip rip database
10.0.0.0/8 auto-summary
10.0.0.0/8 directly connected, FastEthernet1/0
172.16.0.0/16 auto-summary
192.168.100.0/24 auto-summary
<skipped>
R2#sh ip route | i 15.0.0.0
D 15.0.0.0/8 [90/156160] via 10.0.0.2, 00:15:22, FastEthernet1/0
This also means that R1 which runs RIP only will never know about 15.0.0.0/8 network.
EIGRP load balancing using “Variance”
EIGRP is probably the only widespread IGP capable of unequal cost path load balancing. It is quite
easy to configure this feature though there is one important thing to remember about it – such
load balancing has nothing to do with Feasible Successor (FS) elections.
Feasible Successors
As we can see in this example network, EIGRP process on R1 needs to find its way to 10.0.0.0/8. R1
receives the route from R2, R3 and R4. Let’s calculate EIGRP in our head:
• R2: Advertised Distance (or Reported Distance) is 5, Feasible Distance (FD) via R2 is 10
• R3: AD (RD) is 5, FD is 15
• R4: AD(RD) is 20, FD is 25
R2 will become Successor because of the lowest FD (10). R3 will become FS because 5 < 10. R4 will
become nobody because 20 > 10.
Load sharing
Even though the path via R3 is worse in terms of metric than the one via R2 it is still possible to put
this route into RIB table by providing variance command:
router eigrp 10
variance 2
This command increases the reference metric – it multiplies FD of the successor by provided
argument (in this example 2). For our network this means that R1 will put the route from R3 into its
RIB because 15 (the FD of R3) is less than the new reference metric of 20 (10*2=20). R4 will still be
an outsider because 25 is still > 20 and because R4 is not even a FS. We can set variance to 5 but
R4 still won’t be considered.
Once again, EIGRP checks feasibility condition and picks successor and feasible successors first.
Variance multiplier is used only to allow FS into RIB, otherwise it could create routing loops.
How Route Servers work at Internet
Exchange Points
Route Servers are used at points of traffic exchange where big enterprises and ISPs interconnect
with each other to actually create The Internet.
As we know, in order to exchange routing information between Autonomous Systems BGP peering
must be established between each pair of peers because BGP works on top of TCP and does not
create neighborships automatically via some multicast magic like IGPs do in most of the cases. Now
imagine a facility where tens of Autonomous Systems peer. Each time someone new pops up –
everybody has to configure another neighbor. Moreover, some networking policies must be
implemented in different varieties among independent routing domains. Route Servers help to
simplify BGP peering:
As you can see, each participant peers with Route Server only thus full BGP peering mesh is
avoided. Route Server acts like Route Reflector in iBGP – it receives some routing information,
processes it and sends out to other peers.
The most crucial thing here is that Route Server does not forward real traffic. All prefixes have
NEXT_HOP attribute of original router which shared this information with Route Server. All
participants exchange actual traffic across some sort of a switch farm.
OSPF and default routes
This post is about some common mistake again. How to tell OSPF router to announce 0.0.0.0/0?
Usually, we create a static default route and redistribute it into IGP. In the case of OSPF, this won’t
work.
router ospf 1
log-adjacency-changes
redistribute static subnets
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 172.16.10.1
OSPF does not redistribute default routes when redistribute command is utilized. I use static
route redistribution in this example, but EIGRP will behave in the same manner:
R2#sh ip ospf database external
OSPF Router with ID (192.168.100.2) (Process ID 1)
As you can see, redistribute command skipped the static default – R2 does not have this external
route in its database.
Another command must be used instead. You may think of it as of some special form of
redistribution command:
• default-information originate
• default-information originate always
Issued without any arguments it will make the router ASBR and inject an E2 Type 5 default route
into OSPF only if 0.0.0.0/0 is already present in RIB table (for example, it was received from eBGP
peer). The always argument tells the router to originate default even if it has no default in its RIB.
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
default-information originate
…
R2#sh ip ospf database external
OSPF Router with ID (192.168.100.2) (Process ID 1)
Type-5 AS External Link States
LS age: 2
Options: (No TOS-capability, DC)

LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 192.168.100.2
LS Seq Number: 80000001
Checksum: 0x21F9
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 172.16.10.1
External Route Tag: 1
It is a better idea because it is conditional, while static defaults are obviously not. If you have 2 BGP
border routers and receive 0/0 routes from ISPs, you don’t want to attract traffic with a static
default towards a router with failed BGP session. It may also be proposed that having the special
command for default routes is safer in terms of configuration errors – you’re less likely to
redistribute default routes accidentally.
OSPF Virtual Links
OSPF virtual link might not be the best thing which may happen to your network because it either
indicates problems in design or backbone connectivity issues. You may stumble upon some
problem when it’s physically impossible to connect some distant OSPF Area into Area 0 (the
backbone), though I doubt. You may also have some disaster on your backbone which caused Area
0 to split and create 2 separate OSPF domains. Anyway, this topic is not about the reasons behind
virtual links – I’m going to tell you about some ubiquitous mistakes people make when they try to
create an OSPF virtual link.
An example of connecting isolated Area 3 to backbone to fulfill OSPF design rule – all areas must
connect to backbone area:
Virtual links can be created when:
• Both routers are ABRs

• Both routers share common Area – transit area
• One router is connected to Area 0
• Transit area has full routing information e.g. it’s not a stub
Configuration snippet for R1:
router ospf 1
area 2 virtual-link 2.2.2.2
R1:
router ospf 1
area 2 virtual-link 1.1.1.1
The final warning – virtual-link command takes RID or Router ID, not an IP address of the other
router’s interface in transit area.
Torrents and NAT
It’s not a secret that peer-to-peer traffic is tremendously widespread nowadays. It may take up to
90% of all traffic in some parts of the Internet. Many people own dedicated set-top boxes or
simple home PCs which run for months and keep seeding files. We also still live in the age of IPv4
and NAT.
Yet may engineers never think about the behavior of p2p file sharing and ubiquitous NAT
combined. There is a problem – p2p file sharing clients tend to open and keep huge amounts of
TCP sockets. You may dig into your torrent client options and see the defaults. Most of us have
cheap consumer-grade devices which connect us to The Internet (for example, DSL modems
operating in router mode instead of bridge mode). Many of those devices are not capable of
keeping NAT translation tables that big. What you can experience is your file sharing client is ok but
none of other network services seem to work – no HTTP, IM or email – you router is loaded and
can’t accommodate NAT translations for other traffic.
Another problem is when employees use p2p networks at work. It happens all the time. Middle
size enterprises usually have only a couple of public IP addresses for NAT service. So, ideally you
have 65k *2 of streams. If some crooks use their office computers to download and seed lots of
stuff and keep it running 24×7 because power and Internet access are free, the whole network can
degrade. In such situations engineers get orders from above to unleash the witch-hunt.
Make your traceroute tool quick
Traceroute is the second most popular network diagnostic tool after ping. Yet most of the people
do not know how to use it properly.
There is one simple trick – disable domain name resolution for all intermediate hops. In most cases
you don’t really care because you deal with IP addresses. Each time traceroute gets a reply – it tries
to make reverse DNS lookup.
Here is how to do this in Cisco IOS CLI:
traceroute 1.2.3.4 numeric
MS Windows:
tracert -d 1.2.3.4
UNIX:
traceroute -n 1.2.3.4
This tool is used too often to waste seconds every time you need to make a trace.
How to upgrade IOS
Sometimes it is necessary to upgrade the currently running IOS in your Cisco to get rid of some
bugs or enable some features. I personally feel uneasy to remove the current IOS file
from flash: and then upload a new one – the new image can have problems, power might be
interrupted during upgrade, etc. I always tend to free up enough flash: space to accommodate
another IOS image.
Once you have two IOS images stored, you can specify the image that should be booted after next
reset:
Router(config)#boot system flash imagename
You can also have several startup config files and pick one of them:
Router(config)#boot config flash filename
If you use both commands make sure you haven’t mutually mistaken them. I once automatically
typed boot config flash ios_image instead of system and the stupid box treated an image file as its
startup config – I typed sh start but got a huge binary mess as an output :)
The first thing you should check after your router boots up and loads the new image is to check
logs to see if the new IOS version parsed and understood each command of your startup config file.
Engineering career and rapid change of
technology
I’ve stumbled upon one online conversation recently. Someone shared his concerns about the
rapid growth of cloud computing. The point was that cloud computing would kill many jobs and
make lots of engineers and other IT folk redundant.
My instant reaction was – should we really care? It was my understanding that everything in this
world tries to evolve. By the time clouds kick in, most of current engineers will make their careers
and become lazy managers or vogue architects. It won’t matter for them anymore.
I’m sarcastic but you should get my point. Only poor and weak people worry about changes. Surely
you should try to get the best route and deal with the best technologies to boost your career but
you will face changes anyway.
Some particular technology doesn’t mean much once you become experienced. People who once
spent some effort to learn some stuff and then stopped will eventually have problems. You should
practice Systems Approach and teach yourself to see the bigger picture. You will be able to
manipulate whatever building blocks you have.

30 Random Networking and Career Tips

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

30 Random Networking and Career Tips

Enviado por

Direitos autorais:

Formatos disponíveis

Packetfactory.

30 random networking and career tips for

I hope you will enjoy reading it!

My feedback on books ................................................................................................................................. 4

Start with these to get some solid foundation:

• Routing TCP/IP, Volume 1 (2nd Edition) by Jeff Doyle, Jennifer Carroll

Then deeply dig into each technology reading these:

• TCP/IP Illustrated, Vol. 1: The Protocols by W. Richard Stevens for TCP

I hope you got my point.

• with periodic updates

R2 router will have 2 possible paths per external prefix:

• from its eBGP peer ISP2

Moreover, R1 will not send external paths back to ISP1.

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

• Internal EIGRP has AD of 90

• External EIGRP has AD of 170

The second scenario is reversed:

I think this explanation is not very clear.

* i10.0.0.4/30 172.16.1.13 0 100 0 ?

R2#sh ip bgp 10.0.0.4

• Prefer highest Weight (Cisco only)

• Prefer highest LOCAL_PREF

• Prefer locally injected path

added via network or redistribute

added via aggregate-address

• Prefer shortest AS_PATH

Network Next Hop Metric LocPrf Weight Path

R2#show ip bgp 0.0.0.0

Router1(config)# line con 0 [vty 0 4]

Here is the result:

Router1#sh line con 0

never never none not set

Make sure to apply it to both console and vty lines.

For example, I’ve tried to save config by using old-school wr command:

There is an obvious solution – use no ip domain-lookup command to disable DNS lookup:

Router(config)# line vty 0 4

Let’s recall the following things:

The bottom line

Here is some output:

Network Next Hop Metric LocPrf Weight Path

Now we can try to investigate the matter:

R7#sh ip bgp rib-failure

R7#sh ip route 88.0.0.0

route-map set_MED permit 10

Cisco devices have one more interesting addition to this behavior:

* i192.168.222.1/32 172.16.1.10 2 100 0?

You should know about these 3 arguments:

Why emulation is good

Vendors consider that provision of emulation platforms is not an option.

Why getting needed instruments it is unlikely to become reality

• copy file running-config

Here is an example of how it may be implemented on the network:

• SVI 23 on CS1 – 192.168.23.1

Sample config for CS1:

• It was filtered by some inbound filtering

R3 has 15.0.0.0/8 prefix in its RIP table:

R3#sh ip rip database 15.0.0.0 255.0.0.0

R3 shares it with R2:

R2#sh ip ospf database external

OSPF Router with ID (192.168.100.2) (Process ID 1)

Options: (No TOS-capability, DC)

Virtual links can be created when:

• Both routers are ABRs