Kevin Dorrell, CCIE #20765

29 May 2008

Microsoft NLB

Filed under: IP Addressing Services — dorreke @ 16:03

This is not really a CCIE topic, but it is the sort of thing that you should be prepared for in real life.  Microsoft NLB – “Network Load Balancing”.  This allows an application to be served by multiple servers.

The way it works is by using layer-2 multicasts.  When a client wants to talk to a server, (or in this case a virtual server) it puts out an ARP request for the server’s IP address.  The server (one or both, I don’t know) responds with a multicast MAC address.  From then on each frame from the client to the application is addressed to the multicast MAC address.

There are a number of things to consider:

  1. The servers generate IGMP for the IP group corresponding to the MAC multicast address.  If the switch is running IGMP snooping, then this ensures that the multicast frames are sent to the servers and nowhere else.  If the switch is not running IGMP snooping, then the frames are flooded to all ports on the VLAN – the scheme still works, but at the expense of flooding all the client-to-server traffic.
  2. IGMP snooping filters only those packets that are strictly IP, i.e. the ones that have EtherType 0x0800.  There is also a keepalive between the servers, also addressed to the multicast MAC destination, at a rate of 2 packets per second per server.  The Ethertype is 0x886F.  These are flooded to all ports on the VLAN, regardless of IGMP snooping.
  3. If you think about it, this is not really Network Load Balancing, but CPU load balancing.  All client frames go to both servers, and then the servers decide between themselves which packet each server is handling, and which are left to the partner.
  4. It does not work too well through a router.  When a router gets a MAC address in an ARP response, it does not believe it, so it discards it.  The only way I have found to get round this is with a static ARP entry in the router.
  5. Even if you do put a static ARP entry in the router, does it balance the load from the router?  I suppose it depends what algorithm the servers use to distribute the load.  If it is based on the source MAC address, then it won’t work to well through a router!   On the other hand, if it is based on the source IP address, then that means that both servers have to process all packets all the way up to layer-3.  The devil and the deep-blue sea.

27 May 2008

“Still to do” list

Filed under: EIGRP, General, HSRP, IP Routing Protocols, OSPF, Spanning-Tree Protocol, VTP — dorreke @ 10:00

Someone asked me recently what I was going to do now I have my digits … would I go for a second one?  Well, not just yet.  I may have got my digits, but there are still too many things in R&S that take me by surprise.  I have found out that you can be a CCIE and still not know everything yet. :-). So expect about a year of consolidation and blogging before I move to pastures new.

Knowing what
Thou knowest not
Is in a sense

Piet Hein, “Grooks”

Some of the stuff that Keith Tokash has been logging recently on the “CCIE Candidate” blog has pointed the way to some interesting investigations.  Furthermore, there have been a few questions on NetPro that have made me think.  It might even be the case to go to one of Narbik’s boot camps when he is in London.  (Or maybe I’m just looking for an excuse to go back to my home city. 😉  So this page will be a working list of things to do.  Pian piano.


  1. EIGRP uses the metrics at which end of each link: the transmit end or the receive end.  Is it possible to provoke asymmetric routing by configuring different metrics at either end of a link?  Can this result in any unstable topologies?  See NetPro context.
  2. Someone on the NetPro forum tells me that EIGRP uneven load balancing is always process switched.  I thought it was handled by CEF using a weighted hash algorithm.  I have to lab this.  Here is a document I based my belief on.


  1. OSPF uses the cost at which end of each link?  Actually, I already know the answer to this one: each router advertises an LSA for each network it is attached to, along with the outgoing metric of the link.  So, looking at the path of a packet from source to destination, the cost is the sum of the transmit costs on the path.
  2. There are two ways of putting a link into are area: with ip ospf 100 area 0 on the interface, and with network x.x.x.x area 0 in the router section.  In the event of a conflict, which takes precedence?
  3. Ask the same question of ip unnumbered interfaces.

HSRP and Routing protocols

  1. I still need to understand fully the interaction between HSRP and routing protocols.  Hereis a situation where HSRP appears to cause unexpected results from a routing protocol.

LAN Control Protocols

  1. When you have a dot1q trunk, which of the control protocols are send on VLAN 1 and which are sent on the native VLAN (assuming these are different).  I answered a question on NetPro about this and apparently got it wrong.  I need to lab it.

Spanning Tree

  1. Spanning-Tree.  I guess I should ask the same question for Spanning-Tree, which after all is a sort of Distance-Vector algorithm.  Which end of each link is significant.


  1. I keep telling people to beware that a VTP client can update a domain, and so it can.  But it is not as easy as I had once thought.  I need to write up the experiment properly.  I wonder whether the behavior is version dependant.
  2. Furthermore, I really want to investigate VTP transparent.  How transparent is VTP transparent?  Can a transparent switch pass through VTP information, and if so, does the domain name need to match?  How does VTP pruning react to encountering a VTP transparent switch?

There is a load of lab work to do on this.

25 May 2008

EIGRP timers – solution

Filed under: EIGRP — dorreke @ 11:04

A couple of days ago I posted a blog entry about EIGRP timers, but I didn’t have time to explain it properly.  So I just dumped the console logs of the experiment, and left it as a “guess what” challenge.  Now is the time to reveal all.

What I am trying to do is to look at a common misconception about EIGRP hello timers.  By default, the EIGRP hello-interval on most networks is 5 seconds, and the hold-time is 3 times that: 15 seconds.  These values are configurable, but how should they be configured?

The story you read in the books is that the hold-timer must be more than the hello-timer, and preferably 3 times as much.  What the books generally don’t tell you is that:

  • The hello mechanism works independently in each direction.  Hellos from router R1 to router R2 do not necessarily have to use the same parameters as hellos from R2 to R1.
  • The hold time is transmitted to the neighbor in the hello packet.  R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.  This has profound implications if you really want to understand the EIGRP Hello timers.

Let us illustrate this with an experiment:

Now, observe the EIGRP timers.  R1 has a hello-interval of 3 seconds, and a configured hold-time of 10 seconds.  R2 has a hello-time of 30 seconds, and a hold-time of 100 seconds.  At first sight, this looks as though it should be unstable; it looks as if the adjacency should stay up for 10 seconds, then go down, stay down for 20 seconds, come up for 10, etc.  But it doesn’t.  Why not?

Let us look at R1’s view of this relationship:

R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0             Fa0/0.12          74 00:00:25   12   200  0  6

See the hold time?  The neighbor relationship has been up for 25 seconds, and the hold time is 74 seconds, not something less than 10 as we would expect.  What has happened is that R2 has sent a Hello with 100 seconds of hold time.  “Hello, I am R1, if you don’t hear from me in the next 100 seconds, assume I am dead”.

And at R2:

R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0             Fa0/0              8 00:00:35    8   200  0  9

Here we see the hold timer that was configured in R1.

Conclusions: The EIGRP Hello mechanism works independently in each direction.  Each router does not use its locally configured hold time, but the hold time determined by its neighbor.

The really cool thing about this is that if I want to change the interval at which I send out hellos, I don’t need to touch the hold time of any of my neighbors; I just need to configure it locally.

23 May 2008

EIGRP timers

Filed under: EIGRP — dorreke @ 19:15

Well, anyone can see that this blog entry is incomplete.  I am just dumping the console logs here so I can format them up and explain them later.  Anyone care to hazard a guess as to what I am trying to show?  😉


R1#show run int f0/0.12
Building configuration...
Current configuration : 197 bytes
interface FastEthernet0/0.12
 encapsulation isl 12
 ip address
 no ip redirects
 ip hello-interval eigrp 200 3
 ip hold-time eigrp 200 10
 no snmp trap link-status
R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0             Fa0/0.12          74 00:00:25   12   200  0  6

And R2:

R2#show run int f0/0
Building configuration...
Current configuration : 156 bytes
interface FastEthernet0/0
 ip address
 ip hello-interval eigrp 200 30
 ip hold-time eigrp 200 100
 duplex auto
 speed auto
R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0             Fa0/0              8 00:00:35    8   200  0  9

So there you have it …


21 May 2008

[OT] On loyalty and motivation

Filed under: General — dorreke @ 14:01

A chance comment by someone this morning got me thinking about my relationship with Cisco.  What is it that keeps me studying, blogging, and answering questions on NetPro?  I don’t get paid for it.  In fact it has cost quite a lot of time and money so far, what with three attempts at the CCIE lab, and Networkers every year.  So why do I do it?

The main reason must be because I find it interesting and fun.  Being a member of Cisco communities gives a certain sense of involvement and belonging.  If it weren’t for the participation of people like Russ White, Harold Ritter, and Rick Burts, on the NetPro, it is doubtful I would be locked in quite so comprehensively.

A lot of it has to do with Cisco’s apparent openness with information.  That encourages participation.  Try to get too close to Juniper or Checkpoint, for example, and you soon come up against a brick wall of paranoia.

That is not to say the relationship is always smooth.  There are times when I get decidedly disillusioned with Cisco.  For example:

  • When I tried to warn them that the IPv6 Command Reference had fallen off their documentation site, and I got a frosty response saying they could not help me because I didn’t (personally) have a support contract.
  • When I reported to the TAC that their switches were counting collisions as errors.  The TAC argued back: don’t be ridiculous, why shouldn’t collision errors be counted as errors?  I had to quote chapter and verse from the 802.3 spec before they accepted that I wasn’t mad after all.  That bug was fixed in later versions.
  • The lack of any easily affordable evaluation licences for lab work.  Microsoft have a program called TechNet Plus which offers evaluation licences for geeks like me who want to play with the features of their products.  Cisco want the full whack like I was a commercial customer.
  • When their documentation and training materials contain errors sufficient to confuse any student, and do not provide any way to report them.
  • When it impossible to schedule a CCIE lab test within the expiry date of the written test.

At the end of the day, I should remember that Cisco is a commercial organisation, and so they measure their success by the bottom line of the balance sheet.  Cisco has hit on a winning formula – openness and community – that successfully keeps their advocates on side.  In doing so, they raise expectations.  Loyalty is a two-way process.  Let’s hope they continue to meet those expectations.


Collisions are not errors: they are a normal part of the half-duplex media contention mechanism!

15 May 2008

Runts and Overruns

Filed under: General, LAN Switching — dorreke @ 00:00

I am still in a state of euphoria about finally getting my digits after close on four years working on it.  I can hardly believe it.  I keep thinking “#20765” and grinning!

I’ve not blogged for a few days, but that does not mean I have given up.  I have been involved in a couple of interesting conversations on NetPro and DISCUSSiT, so I am going to  lay down a couple of hyperlinks here so as not to lose track of the thread.

The first is entitled “Runts and Overruns“.  To me, “runts and overruns” sounds an alarm bell called “duplex mismatch”.  Duplex mismatch must be the most Frequently Asked Question on NetPro.  One day I shall get round to posting a page about the duplex mismatch issue so I can just point to it rather than re-writing it each time.

What makes this case slightly different is that the OP has set 100/full on both switches.  But when I ask him to confirm that he has a straight crossed-cable (Is that a contradiction?) between the switches he says “As far as we know it is a point to point link (we don’t manage it) there may be some repeaters in it though.”

I don’t have a vast amount of experience with metropolitan Ethernet service providers, but for my money there is likely to be something half-duplex in this link.  Is that normal?  Do service providers normally supply half-duplex or full-duplex links?  Or do they expect you to auto-negotiate?  I am watching for the outcome of this one to put in my experience bank.

It may be due to something completely different of course, but that would still be interesting.

12 May 2008

Yessss! CCIE #20765

Filed under: General — dorreke @ 06:51
CCIE Verification Tool
CCIE Certification Details

Name CCIE Number Track Certification Status Certification Date
KEVIN DORRELL 20765 Routing and Switching Certified 09-May-2008



I would like to thank all those who have helped me on my journey.

My wife Myriam and my sons Peter (15) and Matteo (11), who have been patient with me over the past few months, and very understanding when Saturdays, Sundays and may other evenings, have been sacrificed to lab practice.  It was great to be able to go for a long walk in the countryside this Monday holiday morning.

Paul, who started his CCIE journey at about the same time as I did, but arrived almost two years before me, and encouraged me throughout mine.  The proprietors of the New Delhi Restaurant, Gasperich, for regularly allocating us a 4-seat table so I could spread my NMC lab notes out to discuss over dinner.

The many many helpful people on Cisco NetPro who are so willing and eager to share their experience.  Too many to mention, but especially Rick Burts, Russ White, François Tallet, Marikakis, Jon Marshall, and many many others.

The staff at NetMasterClass for their excellent training material, and especially to Alexei for answering my incessant questions on their DISCUSSiT forum.

Last but not least, the bloggers.  Ethan Banks, whose blog is an inspiration.  Richard Bannister, whose excellent diagrams provided the reading for my train journey to Diegem.  PacketLife, CCIE Journey, and all the others that are listed in my blogroll.

Thank you all.

04 May 2008

IPv6 – Redistributing BGP <–> OSPF

Filed under: IPv6, IPv6 BGP, IPv6 OSPFv3 — dorreke @ 15:42

In the NMC Sample lab, R1 is an IPv6 border router between OSPF and BGP. It has a loopback interface on R1-Lo100, FEC0::1111:1/125, which is part of the BGP domain by virtue of:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125

R1 forms its peer relationship with R3 as it should, and picks up prefixes from there, which it redistributes into OSPF:

R1#show run | sec ipv6 router ospf
ipv6 router ospf 1
area 13 virtual-link
redistribute bgp 100 metric 20 include-connected

But what about that include-connected? Shouldn’t that get our FEC0::1111:0/125 route into OSPF? Apparently not. I found it necessary to do a redistribute connected as well.

R1#show run | sec ipv6 router ospf
ipv6 router ospf 1
area 13 virtual-link
redistribute connected
redistribute bgp 100 metric 20 include-connected

Conclusion? When redistributing IPv6 BGP into OSPF, the include-connected keyword does not seem to work.

I had an issue going the other way too: OSPF–>BGP. It seems it is not enough just to redistribute:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125
redistribute ospf 1 include-connected
no synchronization

You need to specify what to redistribute:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125
redistribute ospf 1 match internal external 1 external 2 include-connected
no synchronization

I want to look these behaviors up in the Command Reference, but for some reason I cannot find the IPv6 Command Reference documents on the Cisco web site.  I can find the Configuration Guide OK, but not the Command References.  I wrote to their HelpLine about it.


NMC Sample lab

Filed under: BGP, IPv6, IPv6 BGP — dorreke @ 10:18

Since we had a couple of holidays this week (week 18), and having given up on lab 18, I thought I would have a go at the sample lab.  Being a showpiece, I thought it might be interesting and representative.

  • S7.7 – BGP auto-summary
  • S.8 – In IPv6, redistribute ospf 1 include-connected does not redistribute the externals by default.  You have to do redistribute ospf 1 match internal external 1 external 2 include-connected.
  • S.8 – Learned the proper syntax for ipv6 BGP validation commands (instead of guessing) 
    • show bgp ipv6 unicast
    • show bgp ipv6 unicast summary
    • show bgp ipv6 unicast neighbor
  • S.8 – IPv6 – Redistributing BGP <–> OSPF


01 May 2008

[OT] No support from Sony Ericsson?

Filed under: General — dorreke @ 22:58

I have a new phone, a Sony Ericsson 550i.  I bought it to replace my old Sony Ericsson K750i whose joystick had packed up.  (I notice that they have removed the joystick from the design now.  Just as well: it was a real dog.  Almost guaranteed to break.)

I wanted to ask a question about compatible flash memory chips for my new phone.  But apparently, because I live Luxembourg, I cannot get support.  If you look at their web site, Luxembourg is not listed.

Being English mother-tongue, I approached the UK site in the hope of getting support in the language I am most comfortable with.  But they refuse to talk to me, telling me instead to contact my local support line.  Obligingly, they sent me a list of their support centres for Europe.  Of course, Luxembourg is not on the list.

I am not impressed.  I shall try Sony Ericsson Belgium and see if that works.  It offers support in French (which I do speak some) and Flemish (which I don’t), but it’s anyone’s guess if that is the right one for Luxembourg.

You would think that an international corporation like Sony Ericsson would offer international support.  Next time I think I shall buy Nokia.

Older Posts »

Create a free website or blog at