Kevin Dorrell, CCIE #20765

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   172.16.12.2             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   172.16.12.1             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:

R1#show run int f0/0.12
Building configuration...
Current configuration : 197 bytes
!
interface FastEthernet0/0.12
 encapsulation isl 12
 ip address 172.16.12.1 255.255.255.0
 no ip redirects
 ip hello-interval eigrp 200 3
 ip hold-time eigrp 200 10
 no snmp trap link-status
end
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   172.16.12.2             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 172.16.12.2 255.255.255.0
 ip hello-interval eigrp 200 30
 ip hold-time eigrp 200 100
 duplex auto
 speed auto
end
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   172.16.12.1             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
router-id 172.16.10.1
log-adjacency-changes
area 13 virtual-link 172.16.130.1
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
router-id 172.16.10.1
log-adjacency-changes
area 13 virtual-link 172.16.130.1
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
exit-address-family

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
exit-address-family

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.

NMC Lab 18 – I give up

Filed under: General — dorreke @ 18:24

I am going to give up on NMC Lab 18 for the moment.  It is really really hard, with lots of strange corner cases and obscure new features.  I shall come back to it when I am in the frame of mind to learn wierdstuff.

At this stage in my preparation I neeed encouragement, not humiliation!

Seeing dot1q tagged traffic in Ethereal

Filed under: General — dorreke @ 16:51

I am having a problem seeing 802.1Q and 802.1P tags in Ethereal.  I am trying to monitor a trunk port using SPAN, and although Ethereal is seeing the traffic, I cannot see the 802.1Q tag .  I have seen this before at work, and it is about convincing the NIC on the PC not to discard the tag.  At work, we found a registry hack to convince the NIC not to strip the tag.

For reference, I am doing it on an HP ZE4603EA laptop which has a National Semiconductor DP83815 MacPhyter 3v NIC, with driver version 1525.292.

Here are some resources:

But despite a search on the Internet, I cannot find a registry hack for this particular NIC.

Humph!

« Newer PostsOlder Posts »

Blog at WordPress.com.