New Role / New DSL Line

I’m going to start with a personal Note:

I accepted a new role at work this week.  In hindsight it is a role I’ve been doing on and off for quite some time (especially the last few months), but now it is formalized and I get a spiffy new title.  No longer is it a “when I have time” diversion; I’m actually liable for stuff.  A bit of a mixed blessing, to be sure.

My new title is ”Director of Technical Operations.”  No more “Enterprise Architect” introductions.  (note to self:  new business cards?)  I’m actually pretty excited about it.  This is a road I’ve wandered across from time to time over the past two decades, but this is really the first time I can walk right down the middle of the road and not worry about someone calling me back.  Well, besides our CTO.  *grin*

But I can sure worry about a car hitting me as I walk down this road!  I have a lot to learn — and I also believe I have a lot to offer.

The beauty is, I still get to design and code as time allows; granted, that may not be all that often at first but with some of the stuff we have planned for this year I sure hope to still participate in the development side.

The trick, as a blogger, will be realizing when a job inspired post is interesting to folks beyond just me.  I don’t know about you, but when I’m learning things, or doing stuff that’s all new and shiny, I just naturally want to write about it.  Share my experience.  Babble on.  Get comments about being giddy. 

I’m forced to admit that sometimes those sorts of posts aren’t real interesting. 

For instance, the one I’ve left attached.  I wrote it earlier this evening.  As I proof-read it I realized this may not be real compelling… I won’t delete it.  Yet.  But I will promise to try and avoid the virtual diary approach to future posts and focus on articles that will hopefully be more interesting.   Or maybe this is interesting to you?  I’m all ears.

Yesterday at work we took delivery of a new DSL router and the accompanying business-class service.  It was a rather interesting delivery, as we had no other Qwest service in our office; the installer had to run a new line from the demarc in the office building’s wiring closet.

Heh.  I definitely got our money’s worth on that install.

I had ordered the new DSL line as it seemed like we need a bit more bandwidth in and out of the office.  We already have dual T-1s, and we use ‘em heavily.  Our phone service is over those, as is the dedicated VPN (router to router) between our office and the production data center.  Mail server, demo/dev web servers, all employee traffic, etc. Oh, and let’s not forget all the streaming audio that seems so popular lately…  The DSL service is quite inexpensive and we could go month-to-month, so I ordered it to see if we could benefit.  If we don’t, I can cancel easily enough.  If we love it, I go year-to-year and save a few bucks a month.

As I said, that was yesterday.  Today I had a chance to fire up the DSL router and make sure everything was working.  No problems there.  Lights came on as expected.

The Symantec 460 firewall we use has two WAN ports, so adding the DSL circuit into the mix seemed like a no-brainer.  However, after I cabled it all up, the firewall wasn’t “seeing” the DSL line.  This was about the point that I realized that the DSL router was probably PPoE (point-to-point over Ethernet) and probably wasn’t actually ready to go yet.  I was right.  It needed credentials.

Ran back to my office, grabbed my laptop and plugged it into the router.  Browsed to 192.18.0.1 and sho’ nuff, there was a welcome page.  Checked my welcome materials and ran through a quick setup thing on the DSL router with a set of generic credentials.  This netted me another set of credentials (ours) so I ran through the setup again and *bing* we’re up for real now.

First order of business, change that default IP address.  Done.  Plug it back into the firewall and we’re live and cooking.  Well, mostly.  While I knew the firewall would support two WAN ports, I hadn’t actually determined how to use them both.  Turns out to be pretty simple:

WAN 2, in the above picture, is the DSL circuit.  So I’m telling the firewall’s router to send 90% of our traffic down the WAN 2 line.  The VPN to the data center is already bound to WAN 1, so hopefully we’ve balanced things out a bit.  Changing the percentage is easy and doesn’t even require a firewall reboot, so I’m sure I may do some tweaking over time.

This sort of load balancing is interesting.  With two different browsers on the same machine, I went to one of those “what’s my IP” web sites.  Each browser had a different address!  So far, the only fallout I’ve noticed is that Meebo is getting a lot of service disconnections.  If I change that WAN 1 load percentage to 0 (everything out WAN 2), then Meebo is happy.  Bummer, it must not keep persistent connections and is getting switched between the two interfaces?.  Maybe I’ll add a static route to the firewall for Meebo…

I’m not a firewall guru or expert, but I like working with these Symantec 400 series units.  They’re pretty slick and easy to use.  I do wish that our 460 offered Proxy ARP support though — but that’s a topic for another article.

Possibly Related posts:

1. Bandwidth Monitoring and …
2. ARP Proxy / Proxy ARP?
3. Routers matter – maybe?
4. Google’s Project TiSP
5. In Firewall Hell