Thursday finds Heather making a sleepy sojourn to Dublin.
Read Monday’s entry.
Read Tuesday’s entry.
Read Wednesday’s entry.
Thursday, 3:30 A.M.
Noooooo… Time to get up. I’m flying to Dublin again today.
Passport, tickets, laptop, spare hard drive, credit card, token ring card. This is how the well-dressed engineer travels. Off to the airport. This will be an expensive taxi ride, but my husband cannot take me, and I’m simply too tired to be safe on the roads.
Arrived at the airport. Slept the whole way there. Taxi was definitely a good idea. Check-in won’t start until 6:50, so I have time to go to the lounge and sleep a little longer.
I’m on the plane and somewhat predictably asleep before we even take off. I woke up for breakfast and then slept until we landed again. If you’re getting the idea that I am not a morning person, you may be correct. If you’re also getting the idea that much of my brainpower goes towards wishing I could sleep more and finding places to sleep, you’re definitely correct.
I’ve arrived at the airport in Dublin, and our reseller is waiting for me in arrivals. Excellent! He’s actually a really sound guy, so I’m quite happy to be working with him. We zoom off to our first appointment, where I’ll be demonstrating Sniffer’s ATM abilities. This should be fun, because I’ve only got a rudimentary grasp of ATM. I keep reassuring myself that all I’ll need to do is drive the Sniffer, and that the person I’m seeing will understand what’s on the screen, but I hate being at a disadvantage.
Also, I’m a bit concerned about getting into this site, as much of what they do is directly related to the military, and both the reseller and I are American. This has caused problems before, where I’ve had to not speak until the people I’m seeing get me through security. I hate that.
The reseller and I go over our day’s plan, which includes another Sniffer demonstration at a food manufacturing facility and a potential demo that afternoon at a large mobile phone manufacturer. Then I’ll give their people some training, and be off home.
We’ve arrived at the first appointment, and it seems to be a totally civilian facility, so no problems getting in. Our client takes us to a meeting room, where I set up my laptop and open an ATM trace file. The lovely thing about Sniffer Pro 98 is that you can open WAN and high-speed files like ATM in it and analyze them without having to be attached to an ATM network. This does make showing the product much easier, as otherwise we’d have to put our ATMBook in line on their network, which involves downing the connection. Many people don’t want to do this. Instead, I can open up this file while still bound to my Ethernet adapter. Way cool!
When I start showing what the Sniffer can do, our client stops me and says he wants to get someone who is more technical. More technical? He seemed to be following it fine. I have a sinking feeling, wondering if this other guy is going to give me a grilling. Oh well, either way I have already told the client that I’m mostly LAN analysis, but that I can get any question that I can’t answer answered for him.
The trace file we’re looking at shows a ping sequence and some telnet over an ATM link. What’s nice about this is that you can see the call setup clearly, as well as the actual ping and telnet packets. So basically, what we’re seeing on screen is as follows:
DTE on VPI/VCI 0.5 starts an SSCOP BGN (request initialization)
DCE on 0.5 replies with an USTAT PDU (unsolicited receiver state info)
DTC on 0.5 then starts with Q.2931 setup.
The CRN = 46, and it shows the called address (39:0000:0000 0000 0000 0000 0000:A14570FA:00) and the calling address (39:0000:0000 0000 0000 0000 0000:A145706E:00)
This is probably the most interesting part of the process, as if you look further into the cell you can see things like the Forward and Backward Peak Cell Rates, QoS classes, and at the very end of the Q.2931 data, you can see the new VPCI and VCI values, in this case 0.32.
Then you’ve got the DCE on 0.5 sending a call proceeding CRN=46; then DCE sending a Connect CRN=46 VPI.VCI 0.32; and DTC responding with a Connect acknowledge CRN=46.
And then the next cell shows an ARP request that is being carried by that connection! Well cool, eh?
Well, the clients seemed to think so, as they want to get in one of our ATMBooks now and test it on their link for a week. The only problem is that another reseller has our OC3-MMF module for the ATMBook, so we need to get another one in from the States.
In case you’re wondering what I’m on about, OC3 refers to the Synchronous Optical Network which describes signal rate multiples for transmitting on fibre. OC3 means it’s running at three times the base rate, or 155.52 Mbps. Whatis.com describes it much better than I can. ;-) Oh, and MMF just stands for multi-mode fibre.
That was a mighty quick demo. One trace file, a little discussion, and they want to get the product in. Agreed. We move on to our next stop, the food manufacturer. I’ve been warned that this one is token ring, so I think I’m good to go. Ah, but there is a surprise in store…
And the surprise is visible on the wall. Type 1 connector. D’oh! I don’t have one of those. But thankfully we’re able to cobble together a connection that allows me to use my RJ45 rat-tail with their Type 1 port. Then I need to change my profile, disable my cardbus card in devices, and enable PCMCIA. I’ve checked their ring speed—16—and my card is forced to 16. No sense in taking chances. Then a reboot and I’m on the ring.
Now, the fellow we saw there was very nice, very nice indeed. And he asked a lot of intelligent questions, and seemed genuinely interested in finding a solution that would see him through both the end of his token ring days and into his new Ethernet network. But for the first ten minutes, I couldn’t understand a word he said.
He had a lovely accent, but after the first five words or so of every sentence, I lost him. “I suppose you’d want to be doing mumble mumble mumble?” Oh yes, of course. “And perhaps you’d be going to mumble mumble mumble?” Um, you could, yes.
Mind you, it’s not that he was actually mumbling. I just couldn’t quite follow him. I probably agreed to some horrible things and don’t know it. (Actually, our reseller would have pointed out anything dangerous, but still.) Anyway, about ten minutes in everything started making sense, so I suppose my ears caught on. After that, it was easy.
His network was interesting, actually. Unfortunate for him, because when I say interesting, I usually mean that it has some problems. For instance, he had thirteen instances of WINS No Response errors, meaning workstations looked for a WINS server and didn’t get an answer from one. Not entirely unexpected, as there was no WINS server. Then he had local routing errors, where two devices on the same subnet are communicating through a router. He’ll be looking into that. He also had ICMP redirects and host unreachables—must be related to his local routing issues. Add some burst errors and 104 broadcast storms in twelve minutes, and I think he’s got some issues to work on.
That said, they are going to Ethernet soon, so he’ll get to start with a more or less clean slate. We’re hoping that we can get our Distributed Sniffer Servers built into his network, so he always has visibility.
Nice fellow. Makes a big difference to demo to someone who is genuinely warm and nice. You can tell, you know.
Time for lunch. Our reseller takes me off to a restaurant, and we have a nice lunch, then we head back to the office for training.
We’ve pulled up at the office, and directly across the street is a huge building site with an enormous hole in the ground. I’m informed that this is the reseller’s next office being built. They seem to be doing well for themselves, which I’m actually quite glad about. I’ve not met anyone from there that I don’t like so far, and that’s unusual when I’m dealing with salespeople.
One of the resellers is very interested in seeing Sniffer Predictor in action. I crank it open and explain the principles behind it. Basically, it takes files that you can save from Sniffer and imports them, creating a network topology map over which you can map actual traffic from your network. Then, you can do some network modeling, things like changing links, increasing devices, and running a simulation when you’ll run out of bandwidth. The power of this is that you’re using a simulation of your network with your types of traffic.
More people file in. I get to show them the basics of Sniffer and how to present it to the customer. It’s actually a really simple product to demo, as you can simulate everything as if you’re on a network from right inside the Sniffer. So I crank open a trace file and show them the Expert Analysis features. Expert Analysis means that the Sniffer looks at all of the traffic in real time and correlates things to come up with Symptoms and Diagnostics. These are indications of conditions that should be looked at. They show both which devices were involved and what the error condition means and could be caused by. Basically, you can look like a networking genius just by reading exactly what the Sniffer tells you. I like that in a product.
Then I show them some of the monitor features, including the graphs showing the Top Ten Talkers and Protocol Distributions. Protocol Distributions is a great one to put on a customer’s site, because out of all of the people who have stated that their network is IP only, only one site ever has been. People forget about their print servers running IPX and AppleTalk, or about users installing new protocols, or just legacy equipment that might be running something different. It’s a great tool.
After that, they ask some questions about Sniffers in a switched environment. Basically, a Sniffer cannot see through a switch. That’s true of both our competition and us—switches do what they do, and they do it well and to everyone. But you can get around this by putting the Sniffer directly into the switch and setting up span or mirror ports to echo all traffic going out of one port to the port the Sniffer is on. For many Cisco switches and a few others, you can actually set up this span port from inside the Sniffer. We’re the only ones who do that.
We then went into a bit about how networks are put together, how putting a switch on your network means you’ve got a minimum of two segments, whereas putting a router on your network means you’ve got a minimum of two networks. And we did a bit with the OSI model, and which layer each device works on.
That instruction brought us up to the time when I had to leave for the airport. Another one of the gentlemen offered to take me there, as it was on his way home. Unfortunately for him, his car was warm and comfortable, and despite fighting it and fighting it, I kept falling asleep. I’d wake up, resolve not to sleep, and then wake up again in a different part of the city. I don’t think I quite apologized enough. I mean, this guy drove me right there, and I was no company at all. Embarrassing.
Arrived at the airport and checked in, just in time to wait for a while. Still, I was there, the flight was there, things were good. We took off more or less on time, and true to form, I slept.
Arrived at London Heathrow, and went in search of my taxi home. Thank goodness I pre-booked. Finally met up with him, and I was home by 8:15. I’m delighted to be home, and even more delighted that we have a national holiday tomorrow, so I can sleep in! Still, I should have some things to report tomorrow, as I need to work on a health check for another customer.
To comment on this diary entry, please post a comment below or follow this link to write to Heather .
Heather Herbert is employed by Network Associates as a Systems Engineer working with their Sniffer Technologies and Magic Solutions product lines. She is MCSE, MCP+I, and CNA certified and working on her Cisco certifications. Born in New York and transplanted to the UK after meeting her husband online, she lives in a true geek household where Nirvana will be achieved as soon as the coffee pot is fully networked.