...applied technology

  • Increase font size
  • Default font size
  • Decrease font size
Home News IP: networks, access, QoS
IP: networks, access, QoS
E-mail Print PDF

"Storm Control", a Tricky Switch Feature

Setting up my home network in my new home in Berlin, it was time to deploy the managed 16 port switch to accommodate all Ethernet connections. It has proven to be beneficial to connect every device using an Ethernet cable instead of the often available WLAN. This is especially valid if there is video data to transfer and the WLAN AP is so far away that the maximum speed is not available. Furthermore I like to be able to isolate single ports and use the port mirror option to monitor the traffic of a host on a specific switch port.

Anyway, after I switched from my temporary dumb 8 port switch to my managed 16 port switch, I noticed that my network printer became unreliable and refused to print. How is this possible?

My first investigation showed that I was able to ping the printer's IP address. Then it was Wireshark time. No reply to the MDNS queries from my Desktop. MDNS is used to find the IP address of a host in a local network without using centrally administered DNS servers. The originating host sends a multicast packet to all concerned hosts on the LAN, e.g. asking for the IP address of "printer.local". The printer would answer with its IP address. But there was no answer visible on the desktop which was about to use the printer. Playing around, I pinged the multicast IP for MDNS, which is I knew that there are a couple of hosts using MDNS, and they all should reply, namely the Samsung printer, the Apple TV box and the AV receiver. Interestingly, there was only one answer visible on Wireshark, which was the Apple TV. Removing this device, I could see now the AV receiver answering my ping. To make a long story short, actually all hosts answered my ping request, but the "smart switch" blocked all succeeding answers after it got a first multicast answer, they never reached the requesting host. The reason is the feature "storm control" which was activated for multicast and broadcast packets. I don't know how exactly it works, but seeing 3 multicast packets (the answers to my ping) enter the switch simultaneously, it kind of panicked and killed 2 of them in an effort to protect my network form being flooded with multicast packets.

After I disabled this feature, I could see all 3 MDNS supporting hosts answer simultaneously my ping request. Also the printer was working without any problem.  I do understand that the switch starts to drop packets as soon as it sees multicast packets entering the switch simultaneously (e.g. my ping answers). But there should be just a single answer to a single MDNS query. Why the switch blocks this printer MDNS query while "storm control" is active remains to be further investigated.

Anyway, disabling storm control in the D-Link DGS-1210-16 solved my problem, and maybe yours, in case you had a similar problem and googled for a solution!

E-mail Print PDF

Monitoring End-to-End IP QoS

Internet is now almost everywhere in the civilized and half-civilized world available. It's only a question of price and Quality of Service. In my home in Bangkok I suffered from an ever changing quality of my Internet connection. Sometimes it is excellent and sometimes extremely slow with almost unusable VoIP Telephony. At those moments I observed a high packet loss using the Ping tool on my PC.

The DSL line is using ADSL2+ and I get about 15Mbps downlink and 1 Mbps uplink. It is connected to TOT's (Telephone Organization of Thailand) network. But the problems I am observing are certainly not on the DSL link, but in the network's backbone or international gateways. My first hop, from my ADSL router to the default gateway in TOT's network, is quite stable.
To get a better impression of my overall quality beyond my punctual observations, I started this little project.

E-mail Print PDF

Your Data: In the Clouds or On Earth?

Data Security for Consumers

Gone are those days when people kept their memories on photo albums, filling shelves in their homes. Shelves are being gradually also relieved of transparency trays, video cassettes and other legacy media. All this could be kept on a few SD cards, fitting easily into your trouser's pockets, or, of course more commonly, onto a hard disk. But how safe are the valuable data there?

E-mail Print PDF

Getting ready for IPv6

The alarm bells are ringing everywhere: we are are out of IPv4 addresses! What does this mean for the end user? Not much yet! There are enough IPv4 addresses for the backbone infrastructure and servers. The bottleneck is on end user side, especially in some booming regions which have not large enough IPv4 pools available. Already today, Carrier Grade NAT (CG NAT) is used to overcome IPv4 address shortages. In this case, subscribers will a private instead of a public IP assigned. But the shortage is not only based on a growing number of individuals using the internet with a PC. Its also based on the increasing amount of devices used per individual and the probably exploding amount of non-human IP users, e.g. machine-to-machine (m2m) applications.

Is there any need for action for the end user? I would say no. As long as the ISPs can assign IPv4 addresses, everything is fine. Actually the ISPs missed to start the migration to IPv6 early enough. So let's wait until the last v4s are gone.... As soon as ISPs are forced to assign IPv6 addresses, the mess begins.

The problem lies not on the network side. An increasing amount of websites are already reachable on IPv6. Sometimes the IPv6 address is only visible on special domains. E.g. besides the test url, which has ONLY an IPv6 AAAA record, e.g. needs IPv6 to be reached, most other Google servers have already IPv6 addresses besides their IPv4 addresses. But those are not returned to the average user; name servers return only the IPv4 address. This should avoid problems with incorrect working dual stack clients. There is an agreement between the network operator and Google necessary to return AAAA records. This shows that simply trying to ping6 an arbitrary domain to see who is IPv6 ready, does not give us a correct picture about the IPv6 readiness. The IPv6 readiness on server / information provider side if bigger, but in some cases hidden.

Ideally most servers will be reachable from IPv6 only clients when the end user IPv6 mass roll-out begins. It should be easy for the hosters to get IPv6 ready. We can expect that only a view servers will be IPv4 only when the mass roll-out begins. For those destinations there are special solutions possible, like NAT64.

On the user side the situation is different. Many consumer devices and applications do not support IPv6. What about ADSL routers, WLAN access points, IPTV boxes, IP telephones, VPN clients for home offices, network printers, mobile phones, digital photo frames, etc.? SIP is a challenge as well.
The ISP would probably provide a new ADSL modem/router, but everything on the private LAN is left up to the users. Not all of those devices need Internet connectivity. But for sure there has to be a co-existence of v4 and v6 for some time. And this mix will probably cause a lot of confusion.

Should I get IPv6 now?

There is actually no benefit to get IPv6 now, if you have IPv4. I see only one reason to get IPv6 in parallel to the existing IPv4 connectivity: For point to point protocols like file sharing, and direct peer-to-peer applications like VoIP and video conferencing, it might be a benefit to have IPv6 as well as soon as a critical mass of IPv6 only hosts exists. In the web 2.0 age, and with ever increasing IP connection speeds, more and more information consumers become information providers. And in the near future, those new private providers might be not in the position to get an IPv4 address, unlike the big players. This makes proxies and translation services necessary. It's unclear what limitations this imposes and how reliable this would work.

Besides this, the professional user might want to test today what impact IPv6 has on his home network, how the existing nodes behave and how to protect the network without the usual NAT protection. Some headaches about incoming traffic can certainly be solved with global reachable IPv6 addresses and such scenarios could be tested as well today already.

IPv6 tunnels

A couple of protocols make it possible to establish an IPv6 tunnel over an IPv4 network. The IPv4 network will be used as link layer for a point to point connection to a tunnel service provider and into the parallel world of IPv6 routing.

There are a couple of ISPs offering IPv6 tunnels free of charge. A very popular one is Hurricane Electric. They offer free IPv6 addresses using the 6in4 tunnel protocol. Their offering can be used to get IPv6 on a single host, or by implementing the tunnel endpoint on a router and make IPv6 available on the whole LAN.

- all hosts can use IPv6
- permanent IP addresses
- all hosts are reachable without special NAT traversal measures and can act as servers
- IPv4 remains available

I have set up a configuration with a separate IPv6 tunnel router, primarily for testing. This provides both, IPv4 and IPv6 in my LAN. Especially it is also interesting to test how I can continue to use my IPv4 only devices in a simulated IPv6 only environment, e.g. my Grandstream VoIP desktop phone and apps like Skype.

The steps are described here:

IPv6 using Hurricane Electric's 6in4 tunnel

E-mail Print PDF

Browsing Privacy

How easy is it for someone to track our movements in the world wide web? Dynamic IP addresses? NAT? Disabling cookies?
This all seems to be of not much help!  Interestingly our individual PC and browser configurations are so diverse that there are rarely two of the same kind! And this information is available for the server. Means two corporations using a common database could identify you as being one and the same person accessing their web pages.
You can put this to the test here:
At least my configuration proofed to be unique out of 1,379,358 tested so far!

IPv6 Privacy Implications

The 128 IPv6 address space is divided into a 64 bit prefix and a 64 bit interface identifier. Especially the interface identifier is of interest here. The Interface Identifier was planned to have the MAC address embedded. The MAC address can identify the used HW uniquely. Furthermore it will tell us the manufacturer plus potentially the type of equipment if there are different MAC blocks used for different products.

This privacy design flaw can be corrected by using the Privacy Extensions. Those do not embed the MAC address and change the Interface Identifier regularly, while listening additionally on the previously assigned Identifiers for some time.
IPv6 privacy extensions are available on many OS, but for example not on iOS (4) and Android (>=2.1). As especially those devices are personal devices, the users are easily re-identifiable if IPv6 is used!