Re: Cisco SLA data access via SNMP?
### On Sat, 18 Nov 2006 01:25:50 -0400, ### Ray Burkholder [EMAIL PROTECTED] casually decided to expound upon ### nanog@merit.edu ### the following thoughts about RE: Cisco SLA data access via SNMP?: RB On one of the systems I'm getting a cricket error of: RB illegal attempt to update +using time 1163791808 when last RB update time is RB 1163791808 (minimum one second step) RB RB RB There was a problem with a number of Tunnel interfaces not getting RB processed. Things are good now. Cisco QoS and SLA's are indeed viewable RB with Cricket. There are also a bunch of Cacti templates available as well... I'm using modified versions of these. http://forums.cacti.net/about4136-0-asc-0.html -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: In Memoriam: Abha Ahuja
### On Sat, 21 Oct 2006 06:32:39 GMT, Fergie [EMAIL PROTECTED] ### casually decided to expound upon [EMAIL PROTECTED] the following thoughts ### about In Memoriam: Abha Ahuja: F Five years ago today. I miss her. She was a great friend. F F http://fergdawg.blogspot.com/2006/10/in-memoriam-abha-ahuja.html Yes. She certainly was. http://www.neebu.net/~khuon/abha/ -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Who wants to be in charge of the Internet today?
### On Fri, 23 Jun 2006 09:09:19 -0700, Warren Kumari [EMAIL PROTECTED] ### casually decided to expound upon Jason Gauthier [EMAIL PROTECTED] ### the following thoughts about Re: Who wants to be in charge of the ### Internet today?: WK My favorite was always the (potential) customers who would call up WK and ask Can I get the Internet in my house? -- I would always WK answer That depends, how big is your house?, but they NEVER got WK it... They have the Internet on computers now!? - Homer Simpson -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Internet 2010 - Predictions for 2010 from a Content Forum and NANOG 37 in San Jose
### On Tue, 20 Jun 2006 09:13:16 -0700, William B. Norton ### [EMAIL PROTECTED] casually decided to expound upon nanog@merit.edu ### the following thoughts about Internet 2010 - Predictions for 2010 from ### a Content Forum and NANOG 37 in San Jose: WBN Content Provider Predictions for 2010 WBN -- WBN Here is the question I put to a group of Content Providers at a content forum: WBN WBN We are sitting around this table in 2010 and we are commenting how WBN remarkable the last few years have been, specifically that: I think it might have been hedged upon in the responses you heard but I'm suprised it wasn't specifically mentioned that there will be a rise in customized content aggregation at the consumer level supported by mobility aspects. Think of RSS feeds but on steroids. This will be promoted by the next generation of portable PIM and communication devices (3G/4G?). It will incorporate the ability to rogram or dynamically figure out a workflow for pulling content (or setting up content services for specific push) and will be situationally aware for the user so as to present the right things in the right format at the right time through the right interface. A simple example: You're walking down the street and get hungry. You pick up your phone and tell it to find you a nearby restaurant that serves gyros. The phone would consult from its local cache of inromation and if it throws a miss, will go out to one of the local searches and after exchanging your locale, will get the names and locations of several restaurants in the area. It will also have gotten the directions to them from where you are. It also knows that you are on foot so it will calculate several transportation options depending on what's available including walking, taxi, busses, trams, etc. Say you pick the bus. it will then determine where the busses are and when the next available one will arrive by consulting the bus service's information server which tracks bus locations via GPS. It can even be smart enough to determine if that bus will have seats available by a combination of usage pattern data gathered over the last week for the time of day and the current number of riders on the bus. It will then signal the bus to stop at the closest stop to you and also tell you how to get to the bus stop. At the same time, it'll go out and do other things like search for the wait-time at the restaurant, pull up a menu, gather reviews of the food, make reservations if necessary... etc. Now mind you that you might not use all the information that's being gathered but it will still be available. In addition to performing these tasks for just the immediate need, the phone may also be constantly updating itself with news stories (in a multimedia format) so you can read during your trip to the restaurant. If an accident occurs that's along your bus route, it will determine if the bus service intends to reroute around it and also calculate alternate routes for you so you can get off at another stop and take some other form of multimodal transportation to your destination. Although I've just describe the function of but one device in one specific situation, you can see the content access is numerous and diverse. And of course all this information will need to be compiled and presented in a unified integrated format that's easy for the user to quickly digest without getting information overload. Now maybe the device doesn't do this all by itself. Maybe it talks to an information broker service which simply streams the precompiled content back. Now despite everything I've written above, I've only very lightly touched the surface. WBN Internet Service Providers Predictions for 2010 WBN -- WBN WBN We are sitting around this table in 2010 at NANOG and we are WBN commenting how remarkable the last few years have been, specifically WBN that: Given the example from above, content providers will require more geodiversity/georedundancy. Local peering will become increasingly important... especially with the wireless carriers. ISPs will have to become more savvy with regards to IP mobility. This will probably be the eventual driver for native IPv6 deployment. Customers will engage in more dynamic traffic shaping at the CPE. There will be an increase in service-based peering clubs/unions. There will be ann increase in demand for seamless layer-1 handoff. The ability to go from wireline to wireless to content push direct to a third-party display and input interface will become smoother regardless of how the end devices are network homed. -- /*===[ Jake Khuon [EMAIL
Re: [eng/rtg] changing loopbacks
### On Thu, 29 Sep 2005 13:25:48 -0700, Bruce Pinsky [EMAIL PROTECTED] ### casually decided to expound upon Randy Bush [EMAIL PROTECTED] the ### following thoughts about Re: [eng/rtg] changing loopbacks: BP what [else] am i missing? BP BP In addition to what others have said, I'd ask: BP BP - - Any ACL's anywhere that filter based on the old loopbacks? BP - - Any VTY access controls on the router based on the old loopbacks? BP - - Any external systems like authentication servers, management systems, BP etc, etc that need the old loopbacks and can't dynamically adapt? BP - - Any internal routing policies that reference the old loopbacks? BP - - Any DNS entries that need to be migrated (CNAME-A references)? Also want to keep in mind things like tunnel endpoints (IPv6, VOIP, multicast, VPN, etc). Barring any sort of advanced config management package, grep and diff become your friends (some would say despite). As a first pass, I'd snarf down all configs and do a grep for the loopbacks to indtify which ones need attention. Then make your changes in each config and do diffs to verify. Then I'd stage out deployment with stub and leaf nodes going last to minimise churn in OSPF. If you've got iBGP going and are using route-reflectors then do the top-most hierarchy first before the lower clusters. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Order of ASes in the BGP Path
### On Tue, 30 Aug 2005 11:02:18 +0100 (BST), Stephen J. Wilcox ### [EMAIL PROTECTED] casually decided to expound upon Abhishek ### Verma [EMAIL PROTECTED] the following thoughts about Re: ### Order of ASes in the BGP Path: SJW from time to time people say 'but the rfc says...'. but theres a big SJW place for precedent and common practice too. True... but the latest BGP draft series attempts to address BCP and updates on 1771. Typically, the answers sought in light of current BGP practices can be found in the draft. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: IMP #1
### On Wed, 01 Sep 2004 14:47:26 -0700, joe mcguckin [EMAIL PROTECTED] casually ### decided to expound upon Peter H Salus [EMAIL PROTECTED], NANOG ### [EMAIL PROTECTED] the following thoughts about Re: IMP #1: jm I wonder if that was the same IMP that was gathering dust in a corner of the jm student/staff lounge in Boelter Hall at UCLA? I used to see it when I would jm pass by there on my way to the library 20 years ago... I wasn't there back then but at least I found a copy of this network diagram to help me envision it. It would seem to have been made before the days of Visio... |8^) http://www.neebu.net/~khuon/humour/images/1969_2-node_map.gif -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Genu/L3 Major Outage
### On Mon, 23 Feb 2004 18:11:51 -0500, Chris Ranch [EMAIL PROTECTED] ### casually decided to expound upon '[EMAIL PROTECTED]' [EMAIL PROTECTED] ### the following thoughts about RE: Genu/L3 Major Outage: CR Gotta love email latencies, where the gasp for help is heard after the CR problem goes away. I think it would be interesting to hear how well or not well INOC-DBA worked out in this situation. Could someone give a short report? -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: IRR/RADB and BGP
### On Thu, 19 Jun 2003 15:46:48 -0700, Kevin Oberman [EMAIL PROTECTED] ### casually decided to expound upon Vandy Hamidi ### [EMAIL PROTECTED] the following thoughts about Re: ### IRR/RADB and BGP : KO You need to have routes registered in the IRR, but not necessarily the KO RADB. The RADB is only a part of the IRR. Many larger ISPs and NSPs KO run their own registries and there are several international KO registries including APNIC and RIPE. There has been at least one free KO database out there. I just don't remember the URL. (It's in the KO archives, but the search may be painful.) RADB mirrors other registries and its server will happily spit out results from multiple sources/mirrors. Thus if you register in say AltDB, your provider will by default get returned your object if they query the RADB server. This of course assumes they are not doing selective source and restricting their searches to that of only RADB. You will want to confirm this with your provider. Tools such as IRRToolSet used for building prefix filters will allow the user to select on a per-query basis (in addition to global) which sources to search against when querying an IRR database. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: scripts to map IP to AS?
### On Thu, 20 Feb 2003 09:11:02 -0800, Martin J. Levy [EMAIL PROTECTED] ### casually decided to expound upon David G. Andersen [EMAIL PROTECTED], ### William Allen Simpson [EMAIL PROTECTED] the following thoughts ### about Re: scripts to map IP to AS?: MJV Dave (and anyone that downloads lookup_as.c), MJV MJV Grab a newer version of traceroute.c -- There is a CLASSFULL piece of code MJV within the 2.9.3 code-base used in lookup_as.c. The newer traceroute.c MJV code removes the 192/8 128/8 testing. This is a cut-n-paste from the MJV newer traceroute-nanog-6.3.0/traceroute.c. It can be cut-n-pasted into MJV your code... Just a reminder to everyone who intends to query the IRR/RADB... Please be nice to the RADB whois server and don't DoS it. Open a persistant connection instead of one for each prefix lookup. For RADB and any other IRR server running IRRd, this can be accomplished by sending a !! in the beginning and keeping the connection open on your end in a seperate thread or something that you then issue the query to. For RIPE Whois based IRR servers, use the -k flag. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: scripts to map IP to AS?
### On Thu, 20 Feb 2003 15:25:52 -0500, [EMAIL PROTECTED] casually ### decided to expound upon [EMAIL PROTECTED] (Jake Khuon) the following ### thoughts about Re: scripts to map IP to AS? : VK Are there any recommendations for caching of the results? Do, don't, not for VK over 72 hours, etc? I think most people that do an AS-enabled traceroute VK are always going to be getting the same answers back for the first few hops VK to *ANYWHERE* - caching at least your local neighborhood could dramatically VK cut the number of queries Another option would be to download IRRd and run it locally in mirror/caching mode then just point your whois queries to it. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Weird networking issue.
### On Tue, 7 Jan 2003 22:32:15 +0100 (CET), Mikael Abrahamsson ### [EMAIL PROTECTED] casually decided to expound upon '[EMAIL PROTECTED]' ### [EMAIL PROTECTED] the following thoughts about RE: Weird networking ### issue.: MA On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: MA MA Sun's hme cards won't go full duplex even though they advertise it to MA remote switch, causing immense headaches to anyone with Sun gear... MA MA That is just not true. I've had several Sun boxes with hme interfaces MA properly autoneg into 100/full with misc equipment, including 3548:s, and MA working properly. Ditto. I'm currently sitting at my workstation (Sun Ultra2) and its hme0 autonegotiates fine with my Cisco 3524XL each and every time. I don't even have to pin any of the interfaces to 100/full. Admittedly I have had problems in the past, namely a bunch of E4500s to some 5000-series switches. Since they were in remote datacenters, I did pin the interfaces on both ends. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Implementation practices
### On Tue, 8 Oct 2002 19:15:34 -0400, Jason Lixfeld
### [EMAIL PROTECTED] casually decided to expound upon
### [EMAIL PROTECTED] the following thoughts about Implementation
### practices:
JL Irrd-discuss didn't have anything at all to say about this, so I thought
JL I'd bring it here for a different, practical perspective.
Hmm... apparently I'm not allowed to post to irrd-discuss since I'm not a
member. I'm getting mail through group-wide exploder. Rather than wait for
me to be added I thought I'd send a reply to this one.
JL I'd like to think that the former is true :) so if that's the case, what
JL are some of the best practices? Is it just as simple as creating a
JL database which RADB mirrors, containing general maintainer, as and route
JL objects then having a private, un-mirrored/non-exported database
JL containing all the nuts and bolts which you run ratoolset (or other,
JL home made widget) against?
This brings to mind a proposal I made many years ago while at a previous
employ. We saw the need to maintain both public and private data and one
thought was to extend the RPSL spec to do it. We were also attempting to
modify IRRd to support this. I know this is not quickly implimentable nor a
BCP and I'm not sure anyone would still be interested but I thought I'd
throw it out again.
Basically, add two optional attributes to each object. These will be
local-acl and access-by. Here is an example aut-num object with the
extensions.
aut-num:AS3549
...
as-in: AS3967 10 AS-EXODUS AND NOT {0.0.0.0/0}
...
as-out: AS3967 AS-GLOBALCENTER
...
local-acl: as-in(FGCSTAFF+rw),
as-out(FGCSTAFF+rw, EXODUS+r)
access-by: ACCESS-FGCSTAFF
In addition, all people/objects referenced in the maint-by: field
should probably have explicit +rw access.
All fields should probably have implicit ALL+r associated with them,
too.
I guess the regex format for the local-acl: object would be
local-acl:\s*(([^\(]+)\(([^-+]+)([+-][rw]+)(\s*,\s*([^\(]+)\(([^-+]+)([+-][rw]+))*)+
or the like.
The local-acl attribute is a local override to the access object which I
will describe below. The access-by references the access object from within
the controlled object.
Although I have not fully fleshed out the access object, here are the key
attributes.
access: ACCESS-FGCSTAFF
acl:aut-num(ALL+r), mnt-by(ALL+r)
acl:as-in(ALL-rw), as-out(ALL-rw)
acl:ALL(ALL-rw), access(FGCSTAFF+rw)
local-acl: acl(FGCSTAFF+rw)
...
mnt-by: MAINT-AS3549
...
The syntax of the local-acl and acl atribute is as follows:
local-acl | acl:attribute(ACLGROUP operator perm)
ACLGROUP will reference another object which defines the entity of the
access and can define method as well as criteria. The operator is either a
+ or - that permits or denies the permission which is either r or w for read
or write. Note that referencing a primary key attribute in an acl or
local-acl attribute will cause any attributes of that object type to inherit
the permissions of the primary key attribute unless explicitly defined by
another acl or local-acl.
The aclgroup can define a single person or group of
persons/networks/hosts/etc. We haven't fully fleshed this out either but
I'm envisioning something like this:
aclgroup: FGCSTAFF
...
acl-permit: [EMAIL PROTECTED]
acl-permit: 204.71.194.200, watchtower.snv2.gctr.net
acl-permit: 206.251.8/24
acl-permit: .neebu.net
acl-deny: .aol.com
...
The first acl-permit specifies a user@host. The second specifies individual
host control. The third is a network access description. The fourth
describes domain access. And the acl-deny is an example of how to deny
based on domain.
--
/*===[ Jake Khuon [EMAIL PROTECTED] ]==+
| Systems Research Programmer, HPN-Global Routing /| /|[~|)|~|~ NETWORK |
| Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / |/ |[_|\| |Inc. |
+==[ Suite C2100, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
Re: What's wrong with provisioning tools?
### On Wed, 12 Jun 2002 18:37:07 -0400 (EDT), jeffrey arnold ### [EMAIL PROTECTED] casually decided to expound upon [EMAIL PROTECTED] ### the following thoughts about Re: What's wrong with provisioning ### tools?: ja On Wed, 12 Jun 2002, Stephen Griffin wrote: ja ja :: I would be really surprised if anything other than mom-and-pop shops ja :: didn't have _at least_ this. ja :: ja :: rtrmon or rancid can do great config archiving and provide difference ja :: output. ja ja I don't think the issue is detecting change as much as it is associating ja change to specific goals/tickets, etc.. If an ACL changes on a router, ja rancid will pick it up, but right now there is no automated way to tell ja whether that was as a result of a customer request or a security breach. I've had quite a bit of experience with config management tools and have written some myself many years ago as did probably others due to the at the time lack of such things. However, many vendors are providing thrid-party solutions. The one I've seen that seems most suited to an ISP environment is GoldWire although to be honest, I have not really looked in-depth into such products for almost a year now so there might be others. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: RADB mirroring
### On Mon, 20 May 2002 13:35:34 -0700, Randy Bush [EMAIL PROTECTED] casually ### decided to expound upon Peter E. Fry [EMAIL PROTECTED] the following ### thoughts about Re: RADB mirroring: RB An IRR not mirrored by the RADB (to act as a member) and not RB mirroring every RR mirrored by the RADB (to hijack the top level) RB seems pointless. RB RB auto-config tools, such as ratoolset, do not use the mirrored data, RB only the origin data. one specifies the list of registries to RB search. so, mirroring by the irr is neither necessary nor RB sufficient, though it can be convenient for lookup by wetware. RADB and other IRRs running IRRd accept a !s command to set (change from default) the specified sources (including mirrored sources). The return for each query is done on a first-hit matching mechanism. One may conceivably switch/modify search orders prior to each query. IRRToolSet (formerly RAToolSet) has the capability of specifying a different IRR server but this means one would incur a penalty for closing and reopening connections between switching servers. It is far better (and friendlier to the IRRs) from a performance standpoint to keep persistant connections to a single server that is fully mirroring. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Large ISPs doing NAT?
### On Thu, 2 May 2002 01:20:40 -0700, Scott Francis
### [EMAIL PROTECTED] casually decided to expound upon Peter Bierman
### [EMAIL PROTECTED] the following thoughts about Re: Large ISPs
### doing NAT?:
SF The average customer buying a web-enabled phone doesn't need a
SF publicly-routeable IP. I challenge anybody to demonstrate why a cell phone
SF needs a public IP. It's a PHONE, not a server.
Time to start thinking a little further down the line. What if the phone
actually becomes an wireless IP gateway router? It routes packets from a
PAN (personal area network) riding on top of Bluetooth or 802.11{a,b} to the
3G network for transit. NAT would certainly become very messy.
--
/*===[ Jake Khuon [EMAIL PROTECTED] ]==+
| Packet Plumber, Network Engineers /| / [~ [~ |) | | --- |
| for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S |
+=*/
Re: Large ISPs doing NAT?
### On Thu, 2 May 2002 10:42:01 +0200, Daniska Tomas [EMAIL PROTECTED] ### casually decided to expound upon [EMAIL PROTECTED] the following ### thoughts about RE: Large ISPs doing NAT? : DT and what if one of the devices behind that phone would also be a personal DT ip gateway router (or how you call that)... you could recursively iterate DT as deep as your mail size allows you to... It's possible. Could it get ugly? Yes. Do we just want to shut our eyes and say let's not go there well... maybe. I just don't think the solution is to say, this can never happen... we must limit all handheld devices to sitting behind a NAT gateway. DT hope this thread will not end in a router behind a router that serves as a DT router seving as a router to another router which has some other routers DT connected... God forbid! We might have a network on our hands! -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Large ISPs doing NAT?
### On Thu, 2 May 2002 11:15:00 +0200, Daniska Tomas [EMAIL PROTECTED] ### casually decided to expound upon [EMAIL PROTECTED] the following ### thoughts about RE: Large ISPs doing NAT? : DT you will end up with exactly two exactly specified services... not that DT bad, is it? Nope... and that was my point. I was simply trying to address a statement that might pidgeonhole the role of a 3G/GPRS device. I think we all should know better than to assume something will never happen. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: packet reordering at exchange points
### On Mon, 08 Apr 2002 14:18:52 -0700, Paul Vixie [EMAIL PROTECTED] casually ### decided to expound upon [EMAIL PROTECTED] the following thoughts about ### packet reordering at exchange points: PV packet reordering at MAE East was extremely common a few years ago. Does PV anyone have information whether this is still happening? PV PV more to the point, does anybody still care about packet reordering at PV exchange points? we (paix) go through significant effort to prevent it, PV and interswitch trunking with round robin would be a lot easier. are PV we chasing an urban legend here, or would reordering still cause pain? I'd imagine that anyone passing realtime streams, Mbone or VOIP (anyone out there routing their VOIP traffic across an IXP?) would start having issues with the resulting jitter. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: How to get better security people
### On Wed, 3 Apr 2002 01:17:59 -0500 (EST), Sean Donelan [EMAIL PROTECTED] ### casually decided to expound upon Christopher E. Brown ### [EMAIL PROTECTED] the following thoughts about Re: How to get better ### security people: SD While we need a few people with deep security knowledge, we also SD need to spread a thin layer of security pixie dust throughout the SD entire organization. It's just like it is within the IETF process... Security considerations must be undertaken by everyone. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: BGP without an IGP
### On Thu, 28 Mar 2002 13:40:51 -0500, Abarbanel, Benjamin ### [EMAIL PROTECTED] casually decided to expound upon ### 'Randy Bush' [EMAIL PROTECTED], Russ White [EMAIL PROTECTED] the ### following thoughts about RE: BGP without an IGP: BA into the AS as IBGP routes. But from what I understood Ken original topology BA he was only talking about reachability within the AS. Reachability between IBGP BA peers that are more than 1 hop away. Unless memory and past email messages serve me wrong, I believe Ken's topology called for full-mesh. BTW, we ran iBGP full mesh without an IGP quite fine. Okay.. so there's a twist... We did it for IPv6 (before Cisco had IPv6 IS-IS) but I see no reason why it wouldn't also work for IPv4. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Route Collector
### On Tue, 26 Mar 2002 08:50:44 -0500, Chris Pace [EMAIL PROTECTED] ### casually decided to expound upon Todd Suiter [EMAIL PROTECTED] the ### following thoughts about Route Collector: CP Is it common or a good idea to have a route collector in a CP datacenter/enterprise environment ? We have 1 router that just collects CP routes using bgp and ospf, then set all servers to use it as the default CP gateway. Is this practical or am I making more work for myself ? So it's doing more than just collecting routes? It's also forwarding traffic? Is it carrying a full table of eBGP routes too? -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Transatlantic response times.
### On Mon, 25 Mar 2002 09:13:20 -0600, Pistone, Mike ### [EMAIL PROTECTED] casually decided to expound upon ### '[EMAIL PROTECTED]' [EMAIL PROTECTED] the following thoughts about ### Transatlantic response times.: MP I was curious if anybody would share what they consider to be average or MP acceptable transatlantic ping response times over a T1. MP I know there are tons of variables here, but I am looking for ballpark MP figures. MP Assume that utilization on the circuit is extremely low, and you are MP measuring point to point across the line. You can also assume no other MP bottlenecks effecting the response times (router performance, or what not). MP Should you see a ~150ms trip? 250ms? 450ms??? Well, I've been seeing around 70ms (+/- 5ms) RTT pings from NYC to LON across AC-1 (Global Crossing) as normal. Granted this is on an OC-48 but bandwidth should not matter much to RTT if the load is light and all you're measuring is ICMP ping. MP Is there any equation to estimate response times? For example, if your MP circuit from A to Z has a 500ms avg response, than that equates to a circuit MP distance of aprox. 5000 miles or something? Assuming you exclude switching latency in the hardware, latency induced by regenerators, etc... spead of light in a medium is a simple distance-rate-time equation with a slight twist: c = nL/t, where n is the refractive index, L is the length, and t is the transmission time difference (double this for RTT). The rest is just simple math. So expected one way time should be: t = nL/c Note -- I believe most fiber optic cables have a refractive index somewhere on the order of 1.4. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Trap and Syslog Query
### On Wed, 20 Mar 2002 08:34:41 +, Matt Duggan ### [EMAIL PROTECTED] casually decided to expound upon [EMAIL PROTECTED] ### the following thoughts about Trap and Syslog Query: MD Q1. What do you think will be the percentage of 'useful' traps from a fault MD management perspective? Of course it all depends upon what you are MD interested in and what the network is doing but some thoughts about the MD volume of useful traps and what those traps are would be really useful :) Everything is useful. |8^) You are right however in that it all depends on what you would consider critical, severe, informative. For instance, I would consider chassis alarms, link hard up/downs, BGP peer up/downs and adjacency failures to be immediately useful since they are directly related to correct operation of the network. Assuming a nominal state, you should be seeing zero of such useful traps. |8^) In practice, I would expect them to make up no more than 5% of your total traps unless you're having a REALLY bad day or suffering through a maintenance window. But again, it all depends on your network topology, how complex it is, what you're monitoring and what kind of services it's carrying (which ultimately defines the former criterias). Now if you extend your definition of useful to things like ACL violations then you might be seeing a lot of those (probably 80% of your traps). MD Q2. Same question as Q1 but for syslog. In general, I think the answer to Q1 holds true for this question too. You might see some things in syslog which you won't see from traps however such as boot messages and this will skew the percentages but in general I think you get nearly a one-to-one relationship between the amount and type of inromation from syslog as from traps. Based upon your description of syslog collectors (distributed and thusn presumably closer to target devices) vs trap collector (central), I would expect you might get a slightly higher number of syslog messages overall due to UDP lossage of traps but of course, not knowing you topology and network loads that's just an off-the-cuff guess. MD Q3. What do you expect the real figures to be based upon the network MD operating normally and what, from your experience, are they likely to be MD under fault conditions? I'm not sure I can provide an accurate answer to that. There are too many variables and unknowns [to me] about your network. MD Q4. What, again from your experience, devices send the most traps and syslog MD messages? - is it that a particular manufacturer are particularly trap-heavy MD for example? I think it has more to do with the configuration of the snmp agent and/or syslog facility than any particular vendor or device type. It also has to do with what the device is doing. For instance, a dialup access server configured to log every user signon/signoff will probably generate more logging information than a core router configured to just log link alarms and adjacencies. In general, I would guess that customer facing devices would be more trap-heavy than core components. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Internet Exchange Questions
### On Tue, 19 Mar 2002 12:46:57 +0100 (CET), Iljitsch van Beijnum ### [EMAIL PROTECTED] casually decided to expound upon Jon Bennett ### [EMAIL PROTECTED] the following thoughts about Re: Internet ### Exchange Questions: IvB This hasn't happened. However, the reasoning still stands: why buy rack IvB space in a remote place and go through all kinds of trouble to install a IvB router there, if you can easily use some kind of switched/multiplexed IvB service from a telco and directly connect with your intended peering IvB partners over it, regardless of where everyone is located. (Hey, does this IvB sound like private interconnects?) Among other reasons, the additive cost of all the loops starts to make this practice prohibitive. I believe Bill Norton's whitepaper, Interconnection Strategies for ISPs, illustrates some of the issues of interconnection economics quite well and identifies where/when it makes sense to go into exchange points or establish private interconnects. IvB This may still happen as ethernet becomes telco-friendlier. But as long as IvB you're in a location anyway, interconnecting with other networks who are IvB there as well is always cheaper and easier. Yes, you can reach a certain economy of scale by consolidating carriers, content providers, ISPs, etc under one roof. Many exchange point providers are banking on the atmosphere of a public market as a major selling point. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: The view from the other side of the fence
### On Wed, 13 Mar 2002 05:51:46 -0500 (EST), Sean Donelan ### [EMAIL PROTECTED] casually decided to expound upon Scott Madley ### [EMAIL PROTECTED] the following thoughts about Re: The view from the ### other side of the fence: SD On Mon, 11 Mar 2002, Scott Madley wrote: SD Let's face it as the industry moves towards a more converged state, we SD haven't even really begun to consider the security implications that SD present themselves in this new enviroment. SD SD With convergence, do you think we will get the best security practices SD from both worlds, or the worst? My off-the-cuff prediction is, as with any convergence process, it will be first the latter and then the former... but then again, I'm a cynic. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: The view from the other side of the fence
### On Wed, 13 Mar 2002 08:00:41 -0500 (EST), Sean Donelan ### [EMAIL PROTECTED] casually decided to expound upon Rajesh Talpade ### [EMAIL PROTECTED] the following thoughts about Re: The view ### from the other side of the fence: SD On Wed, 13 Mar 2002, Rajesh Talpade wrote: SD A network is only as secure as its weakest link SD SD sounds like a cliche, but am afraid this least-common-denominator rule SD will hold as networks converge. SD SD Is there anything we can do to improve this? How can we make sure SD the people who need-to-know find out how to secure their weakest SD links instead of waiting for each company to stumble along their SD learning curve. That's a good question. Unlike the system's world where there seems to be quite a few free as well as commercial toolkits alongside stuff that gets distributed OEM to run security audits (many OSes are preconfigured as part of their installation process to generate periodic audits), there doesn't seem to be many such toolkits for auditting networks as a whole. I think this stems from several reasons (and I'm probably missing a few). [1] Diversity in network designs force security folks to tailor their auditing tools to a particular network. [2] Exposure of homegrown auditting methods and procedures viewed as a security breach so such things simply are kept in secrecy. I suspect however that no one has really developed a comprehensive generic auditting tool or toolkit but instead relies on a combination of handcrafted scripts and security policies to run manual audits instead of automated ones. Someone please prove me wrong. [3] Networks are not really thought of hollistically like a server is in the system's world. Security tools are targetted more towards auditting devices in an individual manner because modelling the entire network is too difficult. I suppose some of the folks doing IDS and/or distributed firewall (Oh Mr. Bellovin? |8^) development may be able to shed better light on the subject. But IDS seems to be a reactive measure rather than a proactive one and distributed firewalls may address some issues with device security but doesn't seem to really touch on enforcing sane routing practises. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Tools used accounting/billing
### On Tue, 5 Mar 2002 15:35:59 -0800, H. Michael Smith, Jr. ### [EMAIL PROTECTED] casually decided to expound upon ### [EMAIL PROTECTED] the following thoughts about Tools used ### accounting/billing: HMS Can anyone suggest tools to use for gathering statistics for billing HMS purposes? I would like to know what tools are most common among ISPs. Depends on how you're billing and how complex a network you have. At the provider I worked at, we billed based on rate and so we collected port level statistics, calculated rate fron in/out octets as needed, and generated billing from that. Our tools were at first homegrown (mainly perl based snmp collectors) but we had started looking at commercial vendor solutions too. One very large requirement was that of fault-tolerance. Having your pollers in one or two locations means you can lose valuable port utilisation statistics during even a small network outage due to counter rollovers at high linerates. It was important to be able to scale out a large number of collectors positioned close in to the target devices with the ability to fall back to a store-and-forward mode and remain there for extended periods of time in case WAN connectivity to the datastore fails and then recover and merge data once connectivity was restored. It was also important to have backup and failover capabilities built into the collector so that a poller/collector could take over for one that has failed. One of the vendors that impressed us was RiverSoft since their architecture lent itself well to establishing a scalable fault-tolerant deployment and was engineered along similar design principles as our homegrown tools. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
