Viewing 3 posts tagged with 'vlan' (Oldest First :: Newest First) Show related: del.icio.us links, tags

Wednesday, June 11 2008, 12:51 AM

Even though they're an over-priced pseudo-monopoly with a track record of shitty customer service and only somewhat better service uptime, I owe Comcast an apology. My internet was down for most of the past weekend, and for most of Monday as well. I figured it was due to the storms that rolled through on the night of the outage (Saturday), but after a couple of days with no service, I started getting mad. I was cursing their name and anything related to them. I was particularly unhappy when I found out that a coworker that lives in my apartment complex had no interruptions in service. After I heard that, I started thinking of ways that my setup would be sabotaging the process.

And then it hit me. As part of my process to convert my firewall machine into a Xen instance, I altered the physical networking layout so my cable modem would plug directly into my "Core Switch", an old Cisco 2924XL. I gave the cable modem service its own VLAN, which would be accessable via my firewall instance running on a Xen machine. What I failed to consider is that managed switches tend to have features that allow for communication with other switches in order to facilitate ease of management and network health. This communication is typically broadcasted to any device that is listening on regular intervals.

These broadcasts are what caused my issue. In a normal residential cable modem service (with Comcast at least), the cable modem latches on to the first network device it hears traffic from, and assumes that it will be the one it deals with when connecting to the internet. By having my cable modem plugged directly into the switch, it was receiving the switch's broadcast messages before my firewall instance had a chance to make itself heard. Because of this, my firewall's attempts to connect to the internet fell on deaf electronic ears.

This was remedied easily enough by disabling spanning tree protocol on the VLAN that my cable modem connects to, and disabling Cisco Discovery Protocol broadcasts on the port it connects to. I don't like disabling spanning tree, because quite frankly, network loops suck. The chance that somehow make a loop in that VLAN is pretty damn low though, so there's not much to worry about.

Let this be a lesson to those with way too much time on their hands, like myself.

cisco comcast frustrations linux networking stp vlan xen

Tuesday, January 23 2007, 12:21 PM

A few weeks ago, I picked up a couple old Cisco 2924XL switches from the MSU surplus store. It was my goal to use them to learn more about the inner workings of Cisco equipment, since our core network at work is comprised exclusively of Cisco equipment. I attempted this once before a few years back, but the switch model I purchased was too old and didn't support IOS - Cisco's Internet Operating System that runs on most of its modern switches/routers - so I wasn't able to achieve my goals. These switches do run IOS, albeit an old version.

Getting them configured really wasn't that hard. It seems that the knowledge that I gleaned from what I've done at work so far was enough to get the basic configuration in place. I ran into a few headaches with what I thought should work compared with what was actually possible, but that was due to a combination of the switch specs and the old IOS image. At work, we have things segregated into many VLANs, and the switch acts as a layer3 gateway for all machines that 'reside' in the VLANs provided by that switch. I was trying to duplicate that with my switches for practice, but no matter what I tried, I could only get one VLAN (VLAN1) to route an IP. I thought it was probably the old IOS image, so I tried to hit Cisco's site to grab a newer image. Unfortunately for me, Cisco's website sucks, and I wasted hours going in circles on their site before learning from someone else that you can't download Cisco software images without a support contract. It would have been nice to see that somewhere in the download area, but no, they'd rather send people in and endless loop of "failed" logins. Grrr.

I was able to pull a few strings and acquired the newest IOS image from a friend who has access to Cisco's software download site. I had the same difficulty after I upgraded the software image, but the error message I got from the newer IOS version proved helpful in isolating the cause. Those switches don't have the capability to run with more than one virtual MAC address, so only one VLAN can be routed with an IP at a time. Once I realized this, I took down the VLAN interface I didn't want to use, an configured the VLAN I did want to use, and everything was peachy. I'm thinking that the same technique would have worked with the old IOS image, but since I don't feel like downgrading, I won't know for sure.

With my new Cisco goodness in place, I was able to play with something I thought up a while back. I bought a few Linksys WRT54GL wireless routers earlier on in the summer, and flashed them with OpenWRT to get Linux on them in a form that I could manipulate. I thought it would be cool to set one of them up in a way that would mimic the networking configuration of my router machine, which has four ethernet interfaces for keeping various parts of my network segregated. Using VLANs, this was possible to replicate in the WRTs. The onboard switch can do VLAN tagging and trunking at a per-port level, so it's possible to replicate the multiple interfaces using seperate VLANs instead of seperate physical interfaces. I was able to replicate the networking for my setup after a good amount of trial and error, with one port allocated for each of the three internal subnets and one for the internet. That left one additional port, which i set up as a trunked port that could carry all VLANs to another VLAN-aware device. Too bad I didn't have any other VLAN-aware devices. After the initial success, I just let it sit.

Well, now I do have some VLAN-aware devices, so I've resumed my experimenting. The VLAN system I set up in the WRTs worked perfectly after I ws able to get over some internal problems in the OpenWRT networking scripts that kept me from using VLANs greater than 9. During some tinkering yesterday, I found that the WRTs can be set into monitor mode without affecting their capability as access points, which allows for the WRTs to function as Kismet drones at the same time as they're functioning as access points. In a corporate setting, this would be a great feature for the security staff. While providing wireless access for employees of the company, the security staff could use Kismet (or another utility) to "patrol" for people that shouldn't be entering the network. I don't have much use for it really, but it is kinda neat to see the various other wireless networks that are in range of my apartment.

cisco kismet networking openwrt vlan wrt54g

Wednesday, May 03 2006, 3:25 AM

I came across this one at work the other day, and I didn't find crap about it anywhere, so I figure I'll post the fix here. I was having a lot of trouble configuring multiple VLAN interfaces on a customer box using the 8021q kernel module. I had never had any issues with it before, so I was pretty stumped. Packets were routing out of the box fine, and seemed to be making it back to the box fine as well. Packet and byte counters were updating fine at the interface level, but nothing was making it any higher in the stack than that. It almost seemed like iptables was blocking the traffic, but that wasn't the case either. After many hours of pulling on my imaginary hair, I came across a setting in /etc/sysctl.conf that caused the problem. When the following setting was present, the added VLAN interfaces didn't work...

When it was set to zero (along with a reboot), everything worked fine. From what I can tell, that setting controls whether the kernel will accept packets into an interface that it feels should be entering the machine from a different interface, based on its routing tables. My problems might have been solved by changing around the routing tables a bit, but this worked as well.

linux networking tips vlan

Related Tags