Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts

Thursday, August 8, 2013

Network Traffic Generation

I was recently asked about options for network packet generation (low volume and highly distributed for measurement, so cheaper slower hardware is OK), and I may as well share.

  • Ostinato aims to be wireshark in reverse.
  • tcpreplay is what it says.
  • For more control over emitted packets, look at hping.
  • Or, if you're programming in Python, look at scapy.
  • The perfSonar toolkit would handle the distributed tests.
  • SmokePing might be simpler for the small-but-distributed case.

That should get you started.

Tuesday, January 15, 2013

The Five Stages of IPv6

I had a note to myself to write The Five Stages of IPv6 but The Networking Nerd beat me to it. Since everyone I've encountered first approaches IPv6 with a serious case of denial, it's an obvious lead-in to find the parallels to the Kübler-Ross model.
  1. Denial: no, I don't need IPv6. Sorry, but yes, yes you do.
  2. Anger: NO, I DON'T NEED IPv6!!! Sorry, but yes, yes you do.
  3. Bargaining: can some other software or hardware do IPv6 translation for me? Load balancers like our F5 units can do it for you, but native is faster and you control it. And NAT is just plain bad, bad, bad. example
  4. Depression: there's too much to do! Start somewhere. Personally, I discovered that it was much easier than I thought. example
  5. Acceptance: now what? Start somewhere!

Friday, September 14, 2012

Wireshark 1.8.0 capture-filter

At least for what I do, the capture-filter options in Wireshark 1.8.0 are definitely on the Need To Know list! I agree with the comment that frequently-used options should not hide behind a double-click. I've been known to mark "too much clicking" as a negative point for an application.

Thursday, April 8, 2010

Grandstream and Belkin

Our telephone service has been so awful (usually we have a lot of static on the line, and it goes out completely once or twice a year) and the price for basic service keeps going up, so I finally relented on my "different connectivity modality for redundancy" stance and picked a VoIP service. We're trying to get it to work right now. I hit a problem that's obvious to me as a network engineer, one that's probably tough to diagnose otherwise.

We have a Motorola Surfboard SB5100 Cable Modem that has its moments of showing its age. When it takes a nose-dive, it uses 192.168.2.100 as its WAN IP address; since that address is not routable (RFC1918), we lose Internet connectivity. However, it randomly comes back to life on its own, so Time-Warner doesn't want to replace my cable modem. The lesson here is that when I log in to the SOHO router and see 192.168.2.100 as the WAN IP address, I assume the cable modem is ill.

Following the directions, the next item we hooked up to the cable modem is the Grandstream HT502 VoIP box. On one side, it connects to the cable modem, so it gets the cable modem's WAN IP on its WAN interface. On the other side towards our home LAN, the default IP address is 192.168.2.1. In order to make almost all network configurations plug-and-play, it also serves DHCP out that interface for your home network. It uses the range 192.168.2.100 to 192.168.2.199 for DHCP by default.

To troubleshoot this, I plugged in my MacBook Pro to the LAN interface of the HT502. I checked my ARP table among many other things, and I saw the MAC address of 192.168.2.1 my default router change. That's when I knew the problem.

But the desired operation is to plug in our SOHO router next. We have a Belkin F5D7230-4 that has some pretty sweet advanced features with a simple interface. Yeah, it's also old and needs an upgrade since it has that Flash bug. Belkin hasn't released firmware to fix a router this old, so I have to reboot it when I can read email but not browse the web. I've had several Belkin routers (I love some of the unique features), and they all use the default IP address 192.168.2.1. Where have we seen that before? Yeah, you can't have two systems with the same IP address on the same network because IP addresses must be unique in order to address unique machines naturally.

Of course, the initial red herring was that I logged in to the Belkin router, and saw that its WAN IP address was 192.168.2.100 because the Grandstream HT500 series, like every DHCP server I've ever seen, starts handing out IP addresses from the bottom of its range. I was sure our cable modem had indigestion, but not so sure that I didn't follow proper troubleshooting data collection first.

Anyway, the fix was easy. Hook up cable modem to VoIP converter to laptop, then use my laptop to browse to http://192.168.2.1/ and go in to the settings to change the default IP address to another permissible RFC1918 private IP address; I picked 172.29.2.1 and changed the first two octets of the DHCP range as well (172.29.2.100 to 172.29.2.199) as well. Update, reboot, renew my laptop's DHCP lease (172.29.2.100 as expected). So then I put the Belkin router on the LAN interface of the Grandstream, and put my laptop on one of the LAN ports of the Belkin router, and network connectivity was back to normal!

We'll have to overlook, for now, that the Grandstream only once gave a dial tone, and I wasn't here to hear it! That will need to be fixed, but for now, I've climbed enough troubleshooting mountains for one evening.