- Test - lists.nanog.org

Engineer headcount calculations
by Luke Parrish 23 Jun '05

23 Jun '05

Measuring a customer service rep's time on a daily basis is a pretty easy and straightforward task. You can get down to the minute by minute level of how a CSR spends their time each day. You can also easily relate that back to customer growth which gives you how many CSR's you need for your next budget year. CSR's have a set of tasks to complete that rarely change day to day. However, what about a network engineer? A day in the life of an engineer: outage resolution proactive projects(some 2 hours and some 300 hours) reactive projects(some 2 hours and some 300 hours) customer escalation escalated network issue maintenance windows writing/researching change management time spent in lab researching network issues turning up new service planning for new service turning down old service taking phone calls from internal business units needing support configuring interfaces for new dedicated customers ip administration(sometimes 3 minutes per request sometimes 2 days of justification on a request) equipment upgrades TAC research equipment evaluation reports shipping equipment boxing equipment meetings etc etc etc etc etc etc, everyone knows where I am going. So the million dollar question, how do you account for their time to prove in a business case that you need to add additional headcount. If you plan on adding 110,000 DSL subs next year then we all know that we have to add engineers to support the network that will have to be built. However, how do you prove that with numbers? I can say, I have to turn up 250 new DSLAMs, 60 new routers, 18 new internet drains, etc etc which I can easily relate back to manhours for turnup. However how do you allocate manhours to maintenance of the network? There are some easy ones, 1 IOS upgrade a year times number of devices on the network, 1 bandwidth upgrade per year times number of CO's, etc etc. But what about the day to day that I listed above? We have to sell this idea to accountants, not other engineers, they only see numbers on paper. Its easy to all of us, we know how many people we need, but how do you put a business case together to sell it? Can anyone out there share what type of system they use to account for engineers time, or really any insight at all would be helpful. One answer would be a system that the engineer would open and close time based tickets everytime they made a move during the day. However I dont know many network engineers at the enable level that are restricted this way, however it is an option. luke

1 0

md5 for bgp tcp sessions
by Todd Underwood 23 Jun '05

23 Jun '05

eric, all, not to pick on eric at all, but since he raised the issue... On Wed, Jun 22, 2005 at 11:42:46AM -0400, Eric Gauthier wrote: > likely need to make modifications to our IGP/EGP setup. Though we filter > OSPF multicast traffic, we wanted to add in MD5 passwords to our > neighbors. just a quick comment here. i would encourage you not to do that. the md5 password hack to protect tcp sessions is rapidly falling out of favor for a number of reasons. among them: 1) it protects against a very limited "vulnerability". for operating systems that stay up for reasonable periods of time, that generate sufficiently random ISNs and that check for in-windowness of syns and rsts, there is a very limited exposure. 2) the cure is worse than the disease: a) many (all?) implementations of md5 protection of tcp expose new, easy-to-exploit vulnerabilities in host OSes. md5 verification is slow and done on a main processor of most routers. md5 verification typically takes places *before* the sequence number, ports, and ip are checked to see whether they apply to a valid session. as a result, you've exposed a trivial processor DOS to your box. b) coordination problems cause downtime. password coordination problems are reported to be a major cause of downtime among peers that i interact with. this downtime is costly and is much greater than the downtime caused by the (theoretical and not actively exploited) tcp "vulnerability" i would encourage everyone to seriously rethink the routine use of MD5 passwords to protect BGP tcp sessions. t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence todd(a)renesys.com www.renesys.com

7 8

RE: md5 for bgp tcp sessions
by Hannigan, Martin 23 Jun '05

23 Jun '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Todd Underwood > Sent: Thursday, June 23, 2005 5:57 AM > To: Richard A Steenbergen > Cc: nanog(a)merit.edu > Subject: Re: md5 for bgp tcp sessions > > > > ras, all, > > On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote: > > On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote: > > rolling out magic code because your > vendor tells you to is a bad idea; That's mostly the result of the calamitous failure in vulnerability release methodology, not Operator stupidity. -M<

3 2

Level3
by Robert Mathews 23 Jun '05

23 Jun '05

Good morning.. Have any noted significant performance issues (routing loops etc.) in interconnects with Level3 infrastructure - particularly in Chicago, New York or Seattle within the last 4 days? Any feedback offline would be great. Thank you.

1 0

Re: Localized mail servers, global scope
by Dave Stewart 23 Jun '05

23 Jun '05

>how many different bandaids are applied. It is time >to re-engineer with the benefit of hindsight. However desirable this may be, don't you agree that no matter what mechanism comes along, there's a huge inertia to overcome. We can debate the correct way to handle email forever. But of greater interest would be how you're going to get everyone to go along and change.

1 0

RE: md5 for bgp tcp sessions
by Barry Greene (bgreene) 23 Jun '05

23 Jun '05

> my understanding is that md5 is still checked before the > ttl-hack check takes place on cisco (and perhaps most router > platforms). new attack vector for less security than you had > before. oh well. ras: > can you confirm that it is possible to implement ttl-hack and > have it check *before* md5 signature checks? You do not have a correct understanding of how GPTM is suppose to work. If you can, you need to do this check as close to the punt out of the data plane as possible. Optimally in the ASIC (if the ASIC can be coded to do a TTL check). On Cisco gear we're coding from inside out - doing GPTM in the routing code (BGP) - then in the receive path wrapper (rACL and CoPP) - then in the ASIC raw queue (if it can) - then in the ASIC's receive path primitives. The GPTM was all about dropping the packet before they got near the route process. If you want more details, let me know and I'll send them privately.

1 0

openning party on 06/25/2005 11pm Coordinated Universal Time
by codewarrior＠cuseeme.de 23 Jun '05

23 Jun '05

morning all , experts i am proud to announce a european cuseeme test reflector cuseeme was a free available peer 2 peer multiconferencing videoconferencing application for mac and pc more info about installation and history: http://www.cuseeme.de/ its open now cuseeme.dyndns.tv CID 0 64/150 regards the the cu-team *********************************** join its free http://www.isabel.de/ and support free cuseeme

1 0

Re: OSPF -vs- ISIS
by Dan Evans 23 Jun '05

23 Jun '05

Thanks to everyone who offered advice and links to resources. The information I've gathered with your help will greatly assist me moving forward, regardless of our decision on which protocol to use. Regards, Daniel

1 0

RE: OSPF -vs- ISIS
by Barry Greene (bgreene) 22 Jun '05

22 Jun '05

> For more information, see the talk by Dave Katz at > http://www.nanog.org/mtg-0006/katz.html > > Also, AOL's experience in switching from OSPF to ISIS is > covered at http://www.nanog.org/mtg-0310/gill.html > the PDF on that page is actually an older version. The full > version I used at NANOG is available at > http://www.vijaygill.com/oi.pdf Add Ryan's talk about other security benefits of ISIS: Implications of Securing Backbone Router Infrastructure http://www.nanog.org/mtg-0405/mcdowell.html Also look at the other ISIS talks and tutorials here: http://www.nanog.org/subjects.html#I

2 1

Shared bandwidth and QoS
by Eric Gauthier 22 Jun '05

22 Jun '05

Heya, We have a situation where multiple organizations are all going to be sharing a gigabit ethernet based Internet feed. We've each agreed to "purchase" a percentage of the cost of the feed. The topology is roughly: (Inbound GigE 802.1q Trunk) ----------------------------------->Collective Router w/eBGP to ISP------>ISP | --Org #1, eBGP Peer 1, SubInt 1 | --Org #2, eBGP Peer 2, SubInt 2 | | .. etc What we'd like to do is to set things up so that each institution always has access to their percentage of the ISP link bandwidth and, if there is additional bandwidth available, provide that everyone. The only way I can think to accomplish this is via rate limits and priority queuing, but it looks as though I'll need to mark and/or rewrite the TOS bits in everyone's packets to do so. Does anyone have a better way of accomplishing this? Eric :)

1 0