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 ### ### 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
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 PROTECTED]> ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
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 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: 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: New worm / port 1434?
### On Fri, 24 Jan 2003 22:59:17 -0800, Josh Richards <[EMAIL PROTECTED]> ### casually decided to expound upon [EMAIL PROTECTED] the following thoughts ### about "Re: New worm / port 1434?": JR> * Avleen Vig <[EMAIL PROTECTED]> [20030124 22:44]: JR> > JR> > It seems we have a new worm hitting Microsoft SQL server servers on port JR> > 1434. JR> JR> A preliminary look at some of our NetFlow data shows a suspect ICMP payload JR> delivered to one of our downstream colo customer boxes followed by a JR> 70 Mbit/s burst from them. The burst consisted of traffic to seemingly random JR> destinations on 1434/udp. This customer typically does about 0.250 Mbit/s JR> so this was a bit out of their profile. :-) Needless to say, we shut them JR> down per a suspected security incident. The ICMP came from 66.214.194.31 JR> though that could quite easily be forged or just another compromised box. JR> We're seeing red to many networks all over the world though our network seems JR> to have quieted down a bit. Sounds like a DDoS in the works. JR> JR> Anyone else able to corroborate/compare notes? First attack packet came in around 2130PST. A tcpdump reveals this: Jan 25 00:05:49.880553 64.159.86.99.2321 > 66.166.158.240.1434: [udp sum ok] udp 376 (ttl 120, id 53207) : 4500 0194 cfd7 7811 f8e8 409f 5663 E...Ï×..x.øè@.Vc 0010: 42a6 9ef0 0911 059a 0180 b3a1 0401 0101 B¦.ð..³¡ 0020: 0101 0101 0101 0101 0101 0101 0101 0101 0030: 0101 0101 0101 0101 0101 0101 0101 0101 0040: 0101 0101 0101 0101 0101 0101 0101 0101 0050: 0101 0101 0101 0101 0101 0101 0101 0101 0060: 0101 0101 0101 0101 0101 0101 0101 0101 0070: 0101 0101 0101 0101 0101 0101 01dc c9b0 .ÜÉ° 0080: 42eb 0e01 0101 0101 0101 70ae 4201 70ae Bëp®B.p® 0090: 4290 9090 9090 9090 9068 dcc9 b042 b801 BhÜÉ°B¸. 00a0: 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1ɱ.Pâý5P 00b0: 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 .åQh.dllhel32hke 00c0: 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe 00d0: 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf¹llQh32.dhws2 00e0: 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f¹etQhsockf¹toQ 00f0: 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend¾..®B.EÔPÿ. 0100: 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.EàP.EðPÿ.P¾..® 0110: 428b 1e8b 033d 558b ec51 7405 be1c 10ae B=U.ìQt.¾..® 0120: 42ff 16ff d031 c951 5150 81f1 0301 049b Bÿ.ÿÐ1ÉQQP.ñ 0130: 81f1 0101 0101 518d 45cc 508b 45c0 50ff .ñQ.EÌP.EÀPÿ 0140: 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j.ÿÐP.EÄP.E 0150: c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 ÀPÿ..Æ.Û.ó ]==+ | 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 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: 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 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: 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 10:58:04 -0800, "Jake Khuon" <[EMAIL PROTECTED]> ### casually decided to expound upon "Abarbanel, Benjamin" ### <[EMAIL PROTECTED]> the following thoughts about "Re: BGP ### without an IGP ": JK> Unless memory and past email messages serve me wrong, I believe Ken's Apparently both memory and email message tracking has indeed served me wrong since I posted to the wrong mailing list. I apologise. -- /*===[ 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 filters, IRRs, and route objects
### On 27 Mar 2002 13:48:09 -0500, Przemyslaw Karwasiecki ### <[EMAIL PROTECTED]> casually decided to expound upon [EMAIL PROTECTED] ### the following thoughts about "Route filters, IRRs, and route objects": PK> Why it is required by some providers to generate explicit, PK> exact route objects, in order to allow routes through PK> their filters? Chalk this up to RIPE181 legacy. In those days of yor, you could only achieve the effect of filtering on those more specifics by registering seperate route objects. Many route objects in the IRR today are byproducts of the blind migration which simply converted RIPE181 formatted objects to RPSL. Although this was great in that it didn't really break anything it also didn't force folks to really learn RPSL and take advantage of the new syntax so many people just never bothered to take their objects and properly convert them. -- /*===[ 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 09:14:11 -0500, "Chris Pace" <[EMAIL PROTECTED]> ### casually decided to expound upon "Jake Khuon" <[EMAIL PROTECTED]> the ### following thoughts about "Re: Route Collector ": CP> Yes, it is forwarding bgp routes. However, it has no serial lines connected. CP> Do you think it is causing unnecessary traffic ? I guess I'm just a little confused. You have your servers pointing default to it which means it's intended to pass traffic but it has no external connectivity and it's passing eBGP routes? How is that possible? I guess it would help me to understand if I knew what you're trying to achieve. CP> - Original Message - CP> From: "Jake Khuon" <[EMAIL PROTECTED]> CP> To: "Chris Pace" <[EMAIL PROTECTED]> CP> Cc: "Todd Suiter" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> CP> Sent: Tuesday, March 26, 2002 9:02 AM CP> Subject: Re: Route Collector CP> CP> CP> > ### On Tue, 26 Mar 2002 08:50:44 -0500, "Chris Pace" <[EMAIL PROTECTED]> CP> > ### casually decided to expound upon "Todd Suiter" <[EMAIL PROTECTED]> the CP> > ### following thoughts about "Route Collector": CP> > CP> > CP> Is it common or a good idea to have a route collector in a CP> > CP> datacenter/enterprise environment ? We have 1 router that just CP> collects CP> > CP> routes using bgp and ospf, then set all servers to use it as the CP> default CP> > CP> gateway. Is this practical or am I making more work for myself ? CP> > CP> > So it's doing more than just collecting routes? It's also forwarding CP> > 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: 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: Change management procedures
### On Thu, 21 Mar 2002 11:57:18 -0500 (EST), Greg Maxwell ### <[EMAIL PROTECTED]> casually decided to expound upon ### <[EMAIL PROTECTED]> the following thoughts about "Change management ### procedures": GM> More specifically, I'm interested in knowing how often blocking-type (i.e. GM> group consent before change) change management is used vs logging type GM> (i.e. recording the change during/after the fact so the change can be At my previous employ, we had two different tracks for CM. One handled domestic, and the other handled international. In both cases, blocking-type and logging-type procedures were used concurrently. CM meetings occured every other day with meeting agendas mailed out at least a day prior and covered events scheduled for at least a week out. GM> reverted, and for root cause analysis). Also, for blocking type change GM> management, I'd like to know how people deal with process latency, GM> emergency changes, approval group selection, etc (if indeed anyone uses GM> consent to manage top-tier staff, I haven't found anyone so far that does). Emergency and near-term events were also discussed in detail. As memory recalls, the CM process for normally scheduled events specified at least a week's notice for turnups and changes. In addition to the actual CM team, each group within engineering and operations (provisioning, network engineering, peering, first and second line ops, etc) had a representative. Each event and maintenance had a case number issued upon insertion of a change request into the system and a person (from the CM team) responsbile for tracking purposes. Process latencies were reported back through the representative of the issuer of the change and then handled on a case-by-case basis. Some changes required approval at different levels depending on whether or not any generic change-holds were in effect at the time. -- /*===[ 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 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: 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: Telco's write best practices for packet switching networks
### On Tue, 12 Mar 2002 12:23:51 -0800 (PST), Ratul Mahajan ### <[EMAIL PROTECTED]> casually decided to expound upon Sean Donelan ### <[EMAIL PROTECTED]> the following thoughts about "Re: Telco's write best ### practices for packet switching networks ": RM> On the downside -- this is yet another instance of conflict between RM> research and operations. Being able to address the (core) routers This may be a repeat discussion but I also wonder if there are some other social level conflicts derived from how one structures their management network. For instance, many providers have a seperate group which handles the corporate IT which is different from the group which handles the production provider network. One could take the stance that the production network should only be reachable from the corporate network and that the management network become an extension of the corporate network. I imagine that many network engineers on the side of the production network might take issue with that (I probably would). For better or worse, many of us have gotten used to managing our backbones under a single umbrella including control over how we design and run our management network. I'd be interested in hearing about some of the practises of bigger providers (assuming I'm not asking anyone to violate security) on how they let their emloyees access their infrastrcture. Do you seperate and outsource your management infrastructure to your corporate IT support? Do you seperate but control it within your production network engineering groups? If so, do you have a special group within network engineering concentrating specifically on management or do you have the same people designing the network also do the management design? -- /*===[ Jake Khuon <[EMAIL PROTECTED]> ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Telco's write best practices for packet switching networks
### On Mon, 11 Mar 2002 04:49:46 -0500 (EST), Sean Donelan ### <[EMAIL PROTECTED]> casually decided to expound upon Vadim Antonov ### <[EMAIL PROTECTED]> the following thoughts about "Re: Telco's write ### best practices for packet switching networks": SD> My simple question is why do exchange point prefixes or backbone SD> network prefixes need to be announced to peers or customers? SD> SD> This has been something which has bugged me ever since I connected SD> a router to mae-east. I think the main justification one could use (and I don't necessarily agree with this) is to aide in troubleshooting. Announcing the space may make it easier for multiple parties to troubleshoot through their backbone. On the flipside of this argument of course is why not filter that space to only your NOCs and engineers? Now the counter-argument to that might be that the space starts to add up in terms of bloating ACLs and such. One could go back and forth on this all day I suppose including arguments for and against troubleshooting from production devices vs troubleshooting from a backend system. Another reason mae-east was announced at least historically may have been to help support activities such as the Routing Arbiter Project. I know from experience that due to the nature of how they were positioned within exchange points, the routeservers needed to be reachable by Merit personnel. However, the proper solution there should have been for only Merit's primary transit provider to carry those routes and possibly filter as much as possible the space except to Merit. There were workable solutions even back then. I think we all just chose the path of least resistance because it was easier and the risk factours were perceived to be low. We all know that was a false assumption. I remember the first smurf attack against mae-east and how it knocked out quite a few peers. -- /*===[ 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 | +=*/
