Kevin Dorrell’s CCIE Study Weblog

04 Jul 2008

Who works for who?

Filed under: General — dorreke @ 21:14

It’s getting like a game of musical chairs.  First we had the announcement a couple of weeks ago that Scott Morris was moving to InternetworkExpert.  Scott had previously been the mainstay of IPexpert.

Now we have an announcement that Narbik has joined up with IPexpert:

IPexpert and Narbik Kocharians Join Forces

 It is with great excitement that we reunite with Narbik Kocharians to offer the most incredible CCIE training value available anywhere! Narbik is a well-recognized triple-CCIE with an outstanding name in the CCIE training space, known for his unique style and magnetic personality. 

Read the full story here.

There seems to be a bit of a ratings war going on between the big three: IPexpert, InternetworkExpert, and NetMasterClass.  I am gratified to see that I am on the “success stories” list of all three, having used materials from all three.  I would always recommend that any candidate should use materials from at least two vendors, otherwise you can get too used to the way a particular vendor phrases his questions.  (P.S. Sorry, I forgot CCBOOTCAMP, which should also be considered one of the “big four”.  I forgot them just because I have not used their materials yet.)

22 Jun 2008

Gripes about my HP Photosmart 3210

Filed under: General — dorreke @ 14:51

This has nothing to do with CCIE.  I’m just using my blog to gripe about an unsatisfactory piece of software.

I have one of those HP All-in-one printer-scanners, the HP PS 3210.  Overall, it works fairly OK, but I do have a number of gripes about it, especially when used on the home network.  I would be very intersted to know if these problems are still present in the more recent all-in-one models.

1. Multi-user scenarios

We have Windows XP on the family computer, and an account for each member of the family.  This doesn’t interact too well with the print driver, especially if you try printing double-sided.  The driver has a feature for printing double-sided: basically it prints the odd numbered pages first, then you turn them over manually, then it prints the even numbered pages.  (Or is it first the evens, then the odds .. ?)

Anyway, you get a pop-up telling you when to turn the pages over, and it doesn’t print the other side until you click “Continue”.  Trouble is, the pop-up comes up in the context of the first person to log in, which is not necessarily the person who asked for the print job.  (Some members of the family have the bad habit of leaving their desktops logged in.)

I tried getting support from HP on this, but they said it was too difficult to fix so they were not going to do anything about it.  Great!  Lots of wasted paper.

2. Must be always powered on

If you start the PC with the printer switched off, then you are in trouble.  The trouble occurs not when you start the PC, but when you try and shut it down.  It comes up with lots of “Program not responding” pop-ups, and does not close down until you kill the HP software by hand.  Is it unreasonable to expect them to have thought of that scenario?

3. Cannot update software any more

This is a knock-on effect from my attempts to solve the double-sided issue.  When I contacted HP support, of course, I got the usual “Are you running the latest version of the driver?”  So I downloaded and installed the very latest version I could find on the web site: 7.0.128.000.  Since then, the automatic software update does not work any more.  It seems to download the files OK, counting the bytes, but then says “Download failed”.   There are several “critical” updates I have not been able to install.

4. Default scan profile not applied to multi-page TIF documents

Being European, I have a default scan profile corresponding to A4 paper.  Definition: 1/16 m² with an aspect ratio equal to the golden ratio, ((sqrt(5)-1)/2).  When scanning a single page document, this works fine.  When scanning a multi-page document, it works fine for the first page.  But for subsequent pages, I must re-apply the profile manually to each page.  That slows me down.  (P.S. Strangely, this happens only if you enable the preview.  If you don’t preview, the profile is applied to all the pages.)

5. B/W threshold is different if previewed.

When scanning in black-and-white, you can set the B/W threshold to determine how light or dark you want the image.  The range goes from 1 (very light) to 255 (completely black).

If I preview the scan, I need a B/W of about 120 for a reasonable copy.  If I don’t do a preview, a setting of 120 gives a very light washed-out image.  Unfortunately, the only way I know to edit the profile is do do a preview, which doesn’t make the adjustment of the non-preview setting very easy.  After a lot of experimentation, I found that a B/W threshold of about 164 gave the correct result in non-preview.

Why couldn’t they make the settings behave the same in preview and non-preview modes?

6. Scanner goes into non-responsive mode.

There seems to be no rhyme nor reason to this.  Sometimes the scan software goes to sleep for up to two minutes just after it has populated the preview window, but before I can click “Accept”.  Sometimes, it gives me back control within two or three seconds.  I have no idea why the difference.  During this time, TaskManager tells me that the CPU is 99% occupied, running the process hpscnvw.exe.

Further Comments

Just in case someone comes across this blog and has the same problems, here are some more things I found out:

Issues 5 and 6 are actually related.  I found out that the “going to sleep” depended on the page being scanned.  I was scanning some old documents for the archives.  These documents were on slips of paper of format 1/3 A4: about 8″ by 4″.  These particular documents had some areas with a mid-grey background, and that was being converted to b/w dot-screen for the purposes of the preview.  That is what was taking the time.

If I ask it to scan without a preview, the whole image comes out a lot lighter, and in fact the mid-grey background gets lost.  It can therefore present the scanned slip in about 15 seconds instead of 2 minutes.  I think I can live with that - at least the printed parts are still legible.

18 Jun 2008

Ethan is back!

Filed under: Uncategorized — dorreke @ 17:11

http://www.cciecandidate.com/?p=473

It’s good to see you back on line Ethan!

 

12 Jun 2008

Ha-Ha! Gotcha!

Filed under: General, LAN Switching — dorreke @ 10:40

Well, they say it is good to be able to laugh at yourself …

So, I took this nice new 2960G-24TC, and I placed it front-down on the floor so I could get at the back panel easily, and I plugged in my console cable, and my power cable, and … absolutely dead!

So, I pick it up to work out what is going on, and it suddenly comes up with:

Base ethernet MAC Address: <omitted>
Xmodem file system is available.
The password-recovery mechanism is enabled.

The system has been interrupted prior to initializing the
flash filesystem.  The following commands will initialize
the flash filesystem, and finish loading the operating
system software:
    flash_init
    load_helper
    boot

switch:

So, I unplug the power cable, and plug it back in again, and it comes up with:

Base ethernet MAC Address: <omitted>
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash...

So I put it back down on the floor …. and nothing more happens … until I pick it up again! Etc.

This went on for a good five or ten minutes.  What is going on?  I suppose it is obvious to anyone that has already fallen into this trap!

 

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 0×0800.  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 0×886F.  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
Omniscience

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.

EIGRP 

  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.

OSPF

  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.

VTP

  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   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.

Older Posts »

Blog at WordPress.com.