January 2011 - Test - lists.nanog.org

Re: The tale of a single MAC
by GP Wooden 02 Jan '11

02 Jan '11

Fresh install and the NICs are Broadcom b57 10/100/1000, I believe. ----- Reply message ----- From: "Randy McAnally" <rsm(a)fast-serv.com> Date: Sun, Jan 2, 2011 8:53 am Subject: The tale of a single MAC To: "Graham Wooden" <graham(a)g-rock.net>, <nanog(a)nanog.org> ---------- Original Message ----------- From: Graham Wooden <graham(a)g-rock.net> > Hi there, > > I encountered an interesting issue today and I found it so bizarre > so I thought I would share it. > > I brought online a spare server to help offload some of the recent > VMs that I have been deploying. Around the same time this new > machine (we¹ll call it Server-B) came online, another machine which > has been online for about a year now stopped responding to our > monitoring (and we¹ll name this Server-A). I logged into the switch > and saw that the machine that stopped responding was in the same > VLAN as this newly deployed, and then quickly noticed that Server- > A¹s MAC address was now on Server-B¹s switch port. ³What the ...² > was my initial response. > Fresh OS install from scratch or did you load an image from an existing server? What make/model of on-board NICs? -- Randy M.

1 0

Unusual BGP nexthop
by Ahsan Tariq 01 Jan '11

01 Jan '11

Hi folks. I am working on a project for which I am using the bgp routing tables from routeviews and their update traces. In some update traces from routviews I noticed that the nexthop field is set to: 255.255.255.255 Is this a valid nexthop ? Is their any meaning or significance to this nexthop ? Any help would be appreciated. Thanks Ahsan Tariq

1 0

What sflow software - Manage Engine Net flow analyzer or Plixer Scrutinizer with Analyzer
by Alex Pinto 01 Jan '11

01 Jan '11

Hi everyone, we currently are looking at sflow options for a commercial collector and analyzer. The core use is for visibility on our network, for quickly detecting source / destination IP addresses, ie where the traffic is going and where is it coming from, the type of traffic would be interesting also but to be honest all which really matters is source / destination. The requirement of the sflow software is to give us options and data very quickly in the event of a DDOS attack so mitigation can occur quickly once we understand what’s happening on the network. The last thing we want is for the software not to work under a DDOS (too much data) thus leaving us blind upon an attack. The quicker the software can report on issues, the quicker we can do something about it. Our current routers are fully sflow capable and both export nicely to both packages. Our findings so far Manage Engine Net flow analyzer has both a Linux and windows version, the software is very light and seems to perform very fast, although light on additional features such as custom reporting, and alerting / in depth packet information. The concern is this software too simple, will it work under heavy load? Based on our needs Manage Engine Net flow costs $2000.00 Plixer Scrutinizer – based on windows the software seems resource intensive but has a MASSIVE amount of extra visibility built into the software including automatic alerts, that being said the software does seem extremely more complex to configure and understand, reports seem to take longer to produce and the information doesn’t seem to be reported as quickly. (ie lags by minutes or so compared to Manage Engine) Based on our needs Plixer Scrutinizer Costs $4000.00 Does anyone have any real life experience on either package the cost different between the two packages doesn’t worry us, it’s all about selecting the correct package knowing the one time we need to access the flow information and get it quick that the package we choose preforms quickly and works. I’d also like to hear from anyone else using another commercial solution, which they would recommend. Thanks in advance Alex

3 2

Happy New Year: Crazy Wiring
by Jay Ashworth 01 Jan '11

01 Jan '11

Here, for those who were involved in the "is that a picture of Manhattan with multiple phone companies" debate last week, is a link to the first of a series of linked blog posts, which contain a lot of those pics, somewhat better cited than I've seen before, along with a large collection of "thank ghod I don't have to deal with that" pictures of wiring catastrophes. http://www.darkroastedblend.com/2007/03/really-bad-wiring-jobs_20.html Happy Gregorian New Year! Cheers, -- jra

1 0