Viewing 6 posts tagged with 'networking' (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

Thursday, February 01 2007, 2:29 AM

I've been playing with Xen quite a bit over the past few weeks, and I must say that I'm becoming a fanboy. I've got it set up both on a machine home, and my colocated server at work. I am using it to break up my existing monolithic Gentoo server environments. I've got a couple main reasons for this.

First off, I'm just tired of having Gentoo in a server environment. It's pretty neat in theory, but in practice, its a beast to maintain. Compiling packages from source takes forever. Gentoo is very much bleeding edge, and because of that, things change often, and said changes aren't always painless. Binary distributions like CentOS definitely are at the opposite end of the spectrum. I've got a lot less free time these days to dink around with this and that, so I'll definitely take the ease of use of a binary distribution, and the relative stabiility in the software environment provided by an enterprise-level OS.

The second benefit to Xen is that I can use it to "disassemble" my current server installs one piece at a time instead of just migrating everything in one fell swoop. I've been slowly taking pieces of functionality out of main Gentoo environment and placing them into smaller single-purpose CentOS environments. This allows for the transition to be much easier, since testing one or two pieces of software at a time is much easier than ten or more. Currently I have separate environments for mysql, jabber, shoutcast, and a communal system logger along with the Gentoo environment I'm working to replace. Eventually, there will be environments for apache, DNS, and email services as well.

The third benefit is an added layer of security. With each service in its own Xen environment, the chances of the entire server being compromised via a single vulnerable service essentially goes away. It also allows for me to set up environments for family or friends without having to worry about them getting into things that they shouldn't be seeing.

Since Xen uses standard linux bridging to handle its internal networking, some pretty neat things are possible. I've got two network interfaces in my colocated box at work. One is connected to the internet, the other is connected to a private network. I only have the environments that require access to the internet connected to the public network bridge, but all of the environments are connected to the private network bridge interface. This allows all of the environments to communicate privately amongst themselves without the traffic ever leaving the physical server. As mentioned before, the second network interface is also connected to the private bridge, so I can (and do) connect other physical machines into the private network, and they see the Xen environments as if they were physical servers.

I was also able to do some more neat networking utilizing ssh and pppd. I found an article a few weeks back when I was looking into some ssh networking tricks, and it described a one-line command to create a ppp connection between two machines with ssh as its transport mechanism. This allowed me to create a tunnel that connected my home network to my private network inside (and outside) my colo box at work. The connection isn't very fast, but it's secure, and pretty stable. Its transparent to my machines at home since the tunnel is initiated by my gateway machine. The Xen environments only need a few static routes added for things to work properly, which is trivial. The only thing I'm doing with it so far is capturing usage statistics from all of the Xen environments via SNMP using Cacti. The slow speed of the tunnel doesn't affect that at all. I might try to set up mysql replication between my mysql environment in the colo box and the mysql environment at home for backup purposes. Who knows. There's a lot of possibility.

I'm thinking of setting up a personal wiki on the site here for various implementation notes, procedures, scripts, and other things. If/when I set that up, I'll post my notes on setting things up there.

Edit: I've documented the SSH PPP scripts in the wiki.

cacti networking pppd ssh wiki 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

Monday, June 05 2006, 3:59 AM

Back when I had roomates, I came across a networking problem that, at the time, I didn't know how to solve. I've had a VPN set up on my gateway machine for quite some time, and I shared my internet connection with the roomates. The problem was that while the roomies were paying their share of the internet and should have full access to it, they shouldn't have routed through the VPN interface to IP ranges that I routed through. In terms of the VPN interface, my computers should be treated as trusted, and all others should be considered untrusted, and barred from access.

That's not really an issue anymore since I live alone now, and my wireless network is protected by X509-authenticated IPSec in addition to 128-bit WEP and MAC address filtering. However, I had some free time tonight, and wanted to see how it's done nonetheless. First off, here's the basics of my setup, in reference to the gateway.

What I was looking to accomplish is this. Any traffic originating from the networks connected to eth0 or eth1 should be able to route out eth3 or ppp0, with the routing choice made by the routing tables. However, any traffic originating from eth2 should not be allowed to travel out ppp0, and all traffic destined for the outside world should be sent out eth3. My current routing tables have specific subnets sent through ppp0, and the rest heading out ex3 as the default gateway.

I accomplished my solution using the ip command. It allows for very powerful routing configuration. First off, I added the following lines to /etc/iproute2/rt_tables.

This just provides names that associate with routing table numbers. They're not necessary, but helpful in keeping tabs on things. Next, I created a routing rule that sends any traffic originating from eth2 to the UntrustWls routing table.

After that, I stuck a rule in to set up the default route. I'll use 10.10.10.10 as my default gateway in the example.

I also had to add the following route, because things weren't working quite right. I think it was because arp traffic wasn't being sent out properly from the gateway box without this route.

That's all! As another supplimental exercise, I figured out how to prevent the untrusted network from sending traffic to the trusted networks using these two rules.

My next related project is traffic shaping. While I don't do a whole lot of downloading/uploading of large amounts of data, it would be really sweet to allow certain types of traffic to take precidence over others. This concept is a little more advanced, and who knows when I'll get to it. We'll see I guess.

firewall linux networking routing tips

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

Wednesday, February 11 2004, 12:30 AM

Nothing really noteworty to report on the events of today except that Matt proved to Steven and I that it is possible to sniff packets over a switched network even if the traffic isn't directed towards you... Guess that shows our naievity. I guess Steven and I were living in the land of THEORY where sniffing anything but your own traffic isn't possible, but in practice it is due the lovely layers of the TCP stack. You can't sniff switched layer 2 traffic unless it's directed to you, but you can fool layer 3 into directing traffic to you, which makes it real easy to sniff. Oh well... Matt wins, this time.

On a completely different subject, I've been noticing a different trend as of late when it comes to the guitar and what I've been playing on it. Ever since I started playing the guitar, I've always been quite content just playing rhythm stuff, laying down the foundation that the song is based on, not really choosing to be flashy in what I play. I've pretty much pulled a 180 in the last few months though. Every time I pick up the guitar and plug in, I'm not really interested in playing the same old power chords over the same old songs anymore. I've been playing completely random stuff off the top of my head, and it's mostly lead-type stuff. I wouldn't believe for a second that I'm actually good at playing in that style or that I have 1% of the musical knowledge and passion that I would need to actually sound good, but I'm doing it anyways. Perhaps it's just because I'm so incredibly bored with playing the same old Metallica and Megadeth songs that I've played hundreds of times... bored with the small palette of sounds that I've made on an instrument that's capable of so much more. Who knows. I'd like to get back into a more regular habit of playing since I've kinda become lazy with it. It's hard to believe that I couldn't be more creative with the music that I play if I worked at gaining some more knowledge and skills. I had a glimmer of originality when I was playing today... a lead lick that sounded very cool to my ears and wasn't something that I just mindlessly replicated from some other song. It would be sweet to be able to do that with regularity.

guitar megadeth networking ramblings

Related Tags