Re: OT: Increasing Cell Phone Signal inside a NOC?
I'm sure a lot of people have the same problem as we are having... Our NOC and Server Equipment is located in No Cell Phone signal zone of our building (It's amazing what metal walls, Server Racks and HVAC Systems will do to Cellphone Signals). I was wondering if anyone out there has found a device that will be able to repeat the Cell Phone signal back into our NOC Server Area's??? You need an LDAP server to fix this ;- Uhm, if your cellphone provider supports call forwarding to another number when the phone is outside of signal range, then you could set up an in-house cordless phone system and everyone could set up their cell to forward to their cordless phone. Talk to any local company selling PBXs and office phone systems for more info on office-wide cordless phone systems. This will work because the transmitters are inside the metal walls and they can be placed to work around obstructions like HVAC or racks. --Michael Dillon P.S. of course, my first answer might have been right too... http://www.innmug.org/information/switchview.html Replace the cordless phone system with 802.11b and VOIP and some LDAP servers and this phoneset http://www.symbol.com/news/pressreleases/press_releases_wirelesslans_vo.html :-)
Re: OT: Increasing Cell Phone Signal inside a NOC?
On Wed, 12 Mar 2003 [EMAIL PROTECTED] wrote: I'm sure a lot of people have the same problem as we are having... Our NOC and Server Equipment is located in No Cell Phone signal zone of our building (It's amazing what metal walls, Server Racks and HVAC Systems will do to Cellphone Signals). I was wondering if anyone out there has found a device that will be able to repeat the Cell Phone signal back into our NOC Server Area's??? You need an LDAP server to fix this ;- :-) One suggestion I haven't seen yet: simply complain. Your cellular service provider may install a new base station in the area if enough people ask them to. Here in Europe, there is 1800 MHz digital service nearly everywhere in and around cities, as long as you're above ground. I haven't encountered a building yet that could kill an otherwise strong signal. It's only when the signal is mediocre to marginal anyway that thick walls will kill it.
RE: 69/8...this sucks
Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. Consider the connection between ISP X and ISP Y. ISP Y and is the provider who wants to null route any bogon traffic, even if ISP X advertises a more specific route for it. EBGP session between 192.168.0.1/30 and 192.168.0.2/30. ISP Y places 192.168.0.2 into VRF X-Real. Also in VRF X-Real is 192.168.1.1 Now a VRF X-Bogon is created containing 192.168.1.2 and 192.168.2.1. And finally the ISP's Default-IP-Routing-Table or other general internet VRF contains 192.168.2.2. 192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected. (for example, create virtual interfaces on a GigE representing each side of a pair in the relevant VRFs and then loop the VLANs of each pair of virtual interfaces -- is there a way to create two paired loopback interfaces to interconnect VRFs rather than extending to a physical connection like I always have?) 192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router in Default-IP-Routing-Table) communicate via IBGP route reflection. Either dynamic or static routing can be used to ensure 192.158.1.1 and 192.168.2.2 know the way to reach each other. BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon feed, and modifies the received routes to set the next hop either into oblivion (eg. out a loopback with no ip unreachables set and a deny ip any any ACL) or to a some kind of DoS/worm tracking server (since almost all of this traffic will be part of some kind of attack or worm, and you will quite probably want to know about it; you can also set your default route in your regular network to such a server that records all traffic received). Policy routing is applied on interface 192.168.1.2 saying set IP default next hop 192.168.2.2 and on interface 192.168.2.1 saying set IP default next hop 192.168.1.1. It would work. I've done things similar to this example in a lab to prove they work. I wouldn't want to let a configuration like this loose on the production internet, though, and anyone who would is probably a _Certifiable_ Cisco Internet Engineer. David.
RE: 69/8...this sucks
Stephen J Wilcox wrote: On Wed, 12 Mar 2003, David Luyer wrote: Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches. The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists. However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped. If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL). Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-) David. [1] Apart from simply being a completely twisted design.
Route Supression Problem
Unless useful to others, feel free to just reply off-list. Background: Tuesday (yesterday) morning around 1am, I got a phone call from one of my transit customers(which seems more like a dream). I, sadly, didn't have the router they are on logging to a server, so it's impossible for me to see exactly what happened. Here's what I have. They received a minor spike in traffic going to them. My router shows the last BGP peer reset about that time, so this could be me sending the global table. His bandwidth then drops to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess (authoratative answer) was the customer flapped their routes once too many times and was suppressed by both of my providers, as I seem to recall the penalty heal rate is in 30 minute increments. First issue is, am I right? If I am, then I need to develop ways to limit the damage done to my customer. Is there a way to setup route supression just under what most people use so that I can have client fix the problem and then clear the suppress on my network to allow them to come back up immediately just under the suppress threshold? Another possibility, although I've not seen reference to it, since the customer only transits through my network and depends on my redundancy, is it possible to hold his routes in the tables and keep advertising them out unless they are down for a set time period (ie, ignore flaps, but drop them if he's down 15-30 minutes)? I've never seen this issue. I was aware supression was possible when I first started learning BGP, and so I have never risked bouncing my peers more than three times in a day, and at that point usually quit playing until the next week. When my peers flap due to DDOS attacks, BGP never stabalizes fully or my providers have protected my networks (though I haven't seen how 69.8/18 will react in this scenario which doesn't have a shorter prefix at the peer). My customer is thinking of multi-homing again after this. Of course, it wouldn't have saved the customer. The reason they left multi-homing is that their network is in the same building and they only have one BGP router. I don't think multiple paths would have saved them. Opinions? Suggestions? Options? -Jack ~We now return you to the 69/8 threads
Re: Route Supression Problem
On Wed, 12 Mar 2003, Jack Bates wrote: traffic going to them. My router shows the last BGP peer reset about that time, so this could be me sending the global table. His bandwidth then drops to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess (authoratative answer) was the customer flapped their routes once too many times and was suppressed by both of my providers, as I seem to recall the penalty heal rate is in 30 minute increments. Were there more flaps than just that last one before everything became very quiet? A flap (up-down transition) has a penalty of 1000. By default (if dampening is enabled), the dampen threshold is 2000. You need at least three flaps to trigger dampening. First issue is, am I right? If I am, then I need to develop ways to limit the damage done to my customer. Yell at your upstreams. Is there a way to setup route supression just under what most people use so that I can have client fix the problem and then clear the suppress on my network to allow them to come back up immediately just under the suppress threshold? Dampening doesn't work on direct eBGP sessions: when the session is lost the dampening info is removed from memory. So dampening your own customers doesn't really do anything. For this reason, it seems curious to me that both your upstreams use rather aggressive dampening. (See RIPE-229 for some considerations on good dampening practices.) Opinions? Suggestions? Options? If this happens again you can simply reset your sessions to your upstreams (one at a time of course) to get rid of the dampening IN THE NEXT HOP AS. However, if the trouble is further upstream this only makes matters worse.
Re: OT: Increasing Cell Phone Signal inside a NOC?
On Wed, 12 Mar 2003, Iljitsch van Beijnum wrote: One suggestion I haven't seen yet: simply complain. Your cellular service provider may install a new base station in the area if enough This is very true and sometimes it works. Even for the small customers. I had a problem with Nextel that required Engineering to come to my house and do some site surveys. Nextel determined that had chosen a poor site for one of their towers and they decided to put another tower on the planning board. So sometimes just one person complaining can help. Andrew --- [EMAIL PROTECTED] http://www.andrewsworld.net/ ICQ: 2895251 Cisco Certified Network Associate Learn from the mistakes of others. You won't live long enough to make all of them yourself.
Re: Route Supression Problem
His bandwidth then drops to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess Still using MRTG? Have you read this? http://www.mit.edu/~rbeverly/papers/rtg-lisa02.pdf Or this? http://rtg.sourceforge.net/docs/rtgfaq.html Have you checked the price of 200 gigabyte hard drives and calculated how long it would take to fill one if you were saving everything RTG could collect? Seriously, how much do you risk losing over one incident like this where you don't have the data to show your customer exactly what happened and give them the impression that you are an amazing TCP/IP guru? MRTG is utterly obsolete; replace it! http://rtg.sourceforge.net And if you can't make it to every NANOG meeting, then do check the website for useful presentations like this one http://www.nanog.org/mtg-0302/ppt/beverly.pdf --Michael Dillon P.S. considering the price of huge disk drives, I'd even consider setting up a system to capture traces of all the traffic whenever a traffic anomally occurs. That way you have even more useful info for a post mortem analysis.
Re: Route Supression Problem
On Wed, Mar 12, 2003 at 06:53:03AM -0600, Jack Bates wrote: traffic going to them. My router shows the last BGP peer reset about that [...] I've not seen reference to it, since the customer only transits through my network and depends on my redundancy, is it possible to hold his routes in the tables and keep advertising them out unless they are down for a set time period (ie, ignore flaps, but drop them if he's down 15-30 minutes)? While perhaps not always an ideal solution, is it possible for the customer to set default to you rather than having to use BGP? You could in turn use static routing back to them for their netblock(s). John
RE: OT: Increasing Cell Phone Signal inside a NOC?
In Finland, it is very usual that cell providers can bring a mini-cell (_not_ a repeater, a real cell) _in_ to the building and wire all floors and especially facilities that are below ground level. In my previous life, I got a cell provider to install an extension to the in-house antenna network to a previously unused area of the basement when we decided to build a new machine room there. Full coverage indeed. :) Well, Helsinki is a city where even the metro system has 100% coverage from all four network operators :) Just call your cell operator customer service and ask for someone who is able to talk about coverage issues. --Kauto
Re: Route Supression Problem
you might want to look at http://psg.com/~randy/021028.zmao-nanog.pdf. then again, you may not. it's depressing. randy
Re: Route Supression Problem
You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. randy
Re: OT: Increasing Cell Phone Signal inside a NOC?
Just call your cell operator customer service and ask for someone who is able to talk about coverage issues. Practically no cell operator provides access to these people. They take coverage reports and if you´re lucky, tell you when it´s going to be fixed. And the subway coverage is far from 100%. Might be 100% on the stations. Pete
Re: Question concerning authoritative bodies.
On Tue, Mar 11, 2003 at 11:07:18AM -0500, [EMAIL PROTECTED] wrote: Can you elaborate on why? You can use a central DNSBL without giving up total control. Shortly after I configured servers to use a DNSBL for the first time, I recognized the need for a local DNSWL and have continued to use one ever since. When I setup other people's servers to use DNSBLs, I help them setup a DNSWL and explain how to maintain it. Hmm...copy of centralized DNSBL + local DNSWL = local DNSBL ? I guess the point is that centralized data is good in some sense, but utimately mirroring, copying, editing, or selective copy of that data will be done by operators in effect to create their own local DNSBL. -ron
Re: Question concerning authoritative bodies.
On Wed, 12 Mar 2003, Ron da Silva wrote: Hmm...copy of centralized DNSBL + local DNSWL = local DNSBL ? I guess the point is that centralized data is good in some sense, but utimately mirroring, copying, editing, or selective copy of that data will be done by operators in effect to create their own local DNSBL. So where can we get copies of the AOL DNSBL? :) I wonder how many MB the zone file is. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Route Supression Problem
On Wed, 12 Mar 2003, Randy Bush wrote: You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. You are right, it is depressing. However, I don't see how the penalty multiplication could happen here, you need a few hops in between for that.
Re: Route Supression Problem
Iljitsch van Beijnum wrote: On Wed, 12 Mar 2003, Randy Bush wrote: You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. You are right, it is depressing. However, I don't see how the penalty multiplication could happen here, you need a few hops in between for that. Ah, but this is the Internet. Jack's two upstreams likely have direct or indirect links between them where they will also receive the route updates in question. Should we change the subject (back) to BGP to doom us all? Peter E. Fry (I believe I said that without swearing. $#[EMAIL PROTECTED])
RE: 69/8 problem -- Would CNN care?
Hi Avleen, When you start crying to the list because your new IP allocation is blocked, I'll try to be the first to tell you that The solution here is *VERY* simple. Like it or not, the 69/8 problem *IS* operational content. If message threads containing operational content offend or disturb you in some way, I recommend that you tune in next week, when I'm sure that there will be plenty of off-topic emails for you to read. -Lee -Original Message- From: Avleen Vig [mailto:[EMAIL PROTECTED] Sent: March 12, 2003 4:06 AM To: Lee Watterworth Cc: North American Noise and Off-topic Gripes Subject: Re: 69/8 problem -- Would CNN care? On Tue, Mar 11, 2003 at 02:06:49PM -0500, Lee Watterworth wrote: Over the last few years CNN has covered many internet tech articles -- various worms, attacks and outages. Think they would care to do a story on this problem? No offense Lee, but OH MY GOD, can we *PLEASE* drop this now? If 69/8 is unreachable by some people, it's REALLY NOT THAT IMPORTANT. If 10% of the internet cannot reach 69/8, then it's the problem of that 10%. I'm sure when people cannot reach it they'll eventually figure it out on their own if they don't read nanog. I really really fail to see why people are making such a big deal out of this. Yes, I agree that's it's an issue and it neds to be discussed, but that happened and was dealt with several posts ago. The solution here is *VERY* simple. If you have address space in 69/8, use it as you want to. If someone can't reach you, that's their problem. If you want to help them fix it, fine. If not, don't. But after the first few emails to NANOG, it's between you and them. Period. -- Avleen Vig Say no to cheese-eating surrender-monkeys Systems AdminFast, Good, Cheap. Pick any two. www.silverwraith.com Move BSD. For great justice!
Re: [Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)]
for all of the $adjective schemes and ideas that have been posted, has anyone (besides jon and few others affected) been doing anything substanitive? outreach, more than any technical 'magic' that we can come up with, is the only 'real' solution (subjective real, what is real to me probably doesn't mean sh*t to you, but, hey, wtf). the media might be good, perhaps some online tech sites (someone with a 'big' name in networking would probably be better able to get exposure/contact than a network nobody) - there are/were some reporter-types lurking on nanog (are you out there??), if you are please help. one thing that has been mentioned is the bogon style filtering in various o/s firewall scripts. anyone thought to contact the authors of those scripts, or of the howtos on places like tldp.org? or is everyone too busy reveling in their technical grandeur the problem is simple: outdated filters. the cause is murkier, but lack of clue is probably the biggest, followed closely by lack of documentation on the part of previous admins (but we all document our work carefully right?!?!) the solution is simple: tell people that their filters are out of date the implementation is difficult only in terms of scale. none of us have the time to call/email or otherwise track down every admin out there, so we have to use the tools available to us (unless you really really think that reinventing the wheel again is a good thing) my $0.02 usd - this network nobody is now returning you to your regularly scheduled ego-fest joshua Richard A Steenbergen [EMAIL PROTECTED] wrote: On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote: Charles Sprickman wrote: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites. These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought will this make me look like an idiot in front of engineers across the entire planet? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this. Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: Route Supression Problem
On 2003-03-12-09:01:23, [EMAIL PROTECTED] wrote: Still using MRTG? Have you read this? http://www.mit.edu/~rbeverly/papers/rtg-lisa02.pdf Or this? http://rtg.sourceforge.net/docs/rtgfaq.html [...] Seriously, how much do you risk losing over one incident like this where you don't have the data to show your customer exactly what happened and give them the impression that you are an amazing TCP/IP guru? MRTG is utterly obsolete; replace it! Ok, let's call a spade a spade. I've been an early adopter of RTG, and am using it for traffic graphing in a production environment (in conjunction with a more tested Cricket/RRD setup, for redundancy and data verification). I think it's a nifty tool, with great potential, a clueful and responsive maintainer, and a loyal user base continually developing and contributing cool stuff. However, like any software in its infancy, RTG is far from perfect. I find it unfair to label MRTG as utterly obsolete, nor to speak of RTG -- or any one tool -- as a drop-in replacement appropriate for all environments. Sure it doesn't scale particularly well, but there's a certain appeal to its simplicity and versatility, which I consider a key to its continued usage in the face of more robust alternatives. -a
69/8 is harder to fix than it looks at first glance
the problem is simple: outdated filters. Agreed, more or less. the solution is simple: tell people that their filters are out of date Sorry, but this fixes nothing. It notifies people that a problem exists but it doesn't fix the filters. Several things need to be done for a lasting fix. - we need to identify where the broken filters are. - we need to find contact information for all those places. - we need to notify all the places that their filters are broken. Already, this is a heck of a lot of work and I would not describe this as a simple solution. But now the real fun begins because all of those people that were notified will reply. - some will tentatively accept your info but ask for proof that their filter is broken. - some will strongly deny that anything is wrong with their filters - some will ask what will fix their broken filter - some will ask whether your fix is short term or whether it is general enough to handle similar issues And therein lies the crux of the problem. We have no good answer to this last one other than to tell these people to change their filters today and then to regularly hunt through some mailing lists or websites to find notifications that the filters need to be changed again. And again. And again and again and again. When does it stop? The fact is that are operating these 21st century networks using 19th century business technology. This does not scale. The net is too big to be managed by person to person exchange of information. That's why we have DNS protocols instead of issuing updated copies of the hosts file. And that's why we need an automated system to publish current status of IP address ranges in a format that would be acceptable to firewall admins and firewall vendors. These people already trust LDAP enough to use it for distributing keys and certificates. IP address range attributes are similar sorts of out-of-band information that is not essential to packet forwarding but needs to be distributed in order to configure devices correctly. In this case, the attribute that we are primarily interested in distributing is whether or not an IP address range has been allocated by ARIN for use or not. But there are other useful attributes that could be distributed as well such as contact information. Let's all stop this lazy style of knee-jerk engineering that assumes all problems are simple and can be solved using a router and some PERL scripts. Some problems are hard technically and socially. These kinds of problems can only be solved if you are willing to look at the big picture as well as the immediate impacts. --Michael Dillon
Re: 69/8 is harder to fix than it looks at first glance
On Wednesday, Mar 12, 2003, at 12:11 Canada/Eastern, [EMAIL PROTECTED] wrote: The fact is that are operating these 21st century networks using 19th century business technology. This does not scale. The net is too big to be managed by person to person exchange of information. That's why we have DNS protocols instead of issuing updated copies of the hosts file. And that's why we need an automated system to publish current status of IP address ranges in a format that would be acceptable to firewall admins and firewall vendors. The DNS is managed by person-to-person exchange of information, and it scales. HOSTS.TXT was an example of a centrally-managed database, which didn't scale. Your examples seem to be backwards in some way. Most of the Internet operates on the basis of person-to-person (or router-to-router, or AS-to-AS) information exchange, a characteristic which has *allowed* it to grow. Information which cannot be distributed in this manner frequently becomes troublesome to administer and mired in policy discussion with little forward momentum (e.g. the contents of the root zone, IP address assignments). Saying that the Internet is too big for distributed information processing to scale (and promoting centralised management of information as a preferred alternative) is just odd. Joe
Re: 69/8 problem -- Would CNN care?
Post Hopping: From: Avleen Vig No offense Lee, but OH MY GOD, can we *PLEASE* drop this now? If 69/8 is unreachable by some people, it's REALLY NOT THAT IMPORTANT. If 10% of the internet cannot reach 69/8, then it's the problem of that 10%. I'm sure when people cannot reach it they'll eventually figure it out on their own if they don't read nanog. Avleen, Stop for a minute and realize that 69/8 isn't just given to web-hosters. If that were the case, I'd agree with you. 69/8 is being given out to ISPs that have to feed companies and end users. This has an impact on the ISPs in question, as they cannot provide as good a service as their competitor because various networks are dropping their packets to the floor. Do I complain? Do I add my own speach to this never ending thread? Yes. I do. I need solutions to what isn't just a technical problem, but a business problem. If it doesn't get fixed, I will lose money. I personally am greatful for all the suggestions, work, and communication existing on the list and off-list concerning this problem. -Jack
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Thus spake JC Dill [EMAIL PROTECTED] p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really. 1) nanog can sometimes take hours to forward posts to all members 2) the people directly involved in the thread reasonably expect to get responses immediately 3) seeing your name in the To/Cc line may attach greater importance to the message 4) duplicates can be automatically blocked by procmail with: :0 Wh:.msgid.cache.lock | formail -D 8192 .msgid.cache S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: 69/8...this sucks
Thus spake Jack Bates [EMAIL PROTECTED] After the renumber, I'll only have 69/8 space, which means all critical services such as my mail, dns, and web servers will all be affected. I hear it now. I didn't receive mail from so and so! I check the logs and don't see an established connection to my server. So, is the problem that the far mail server lost the message, the user emailed the wrong place, or my new IP addresses weren't accessible by the far mail server or the dns servers that it uses? There's several BCPs that tell you to have at least one DNS server and at least one unfavorable MX off-site. If you did this, your mail would be safe, albeit a little slow from misconfigured sites. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Route Supression Problem
Dampening is done on the eBGP router where the route enters the AS, and, unless I'm mistaken, per route/path and not per prefix. So the flapping that ISP A sees from ISP B is a completely seperate thing from the flapping that ISP A sees from its customer's customer as far as the dampening algorithm is concerned. Nope. It's per-prefix. Have a look at the pointer Randy provided. I think one of the section of RFC 2439 alludes to this as well. -danny
RE: 69/8...this sucks
I'm trying to get some time to actually put it in a router and test, but I believe there is a way to get similar functionality through a combination of route-map entries. When I have actual router config (I'll be testing on Cisco, but if anyone want's to provide me a Juniper testbed, I'll be happy to try that too), I'll post it. If I can't, I'll post a public apology and start beating on vendors to make it possible. :-) Owen --On Wednesday, March 12, 2003 11:41 PM +1100 David Luyer [EMAIL PROTECTED] wrote: Stephen J Wilcox wrote: On Wed, 12 Mar 2003, David Luyer wrote: Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches. The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists. However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped. If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL). Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-) David. [1] Apart from simply being a completely twisted design.
RE: OT: Increasing Cell Phone Signal inside a NOC?
Some sort of in-building cell repeater may be sufficient. The gating item, I believe, is whether you can receive adequate cellular coverage outside the building (e.g. on the roof). If so, then a simple repeater should be sufficient. If not, then a wired micro-cell would seem to be required. If signal is adequate up on the roof, then you may be able to construct a purely passive repeater, composed of a high-gain outdoor antenna, some coax, and an appropriate in-door antenna located in your no-signal area. If you want some horsepower, you can consider amplified cellular repeater systems. (Nextel used to install these for customers all the time. But they ONLY covered SMR band!) One example of an active antenna repeater system: http://cellantenna.com/repeater/building_repeater.htm I have yet to locate a dual (or tri) band amplified repeater system. They would be nice, to ensure that both 800 and 1900 bands worked, so ALL cell/PCS phones would just work. If you toss in the SMR bands, then all cellphones AND Nextel would just work. (employees wouldn't be restricted to using just one vendor, or one band.) Also, some 800Mhz-band cellphone companies have purchased additional RF capacity up in the 1900-band. Depending on how the cell companies ultimately use the new spectrum, your employees may not receive minimum call-blocking rates, or may not be able to access cellular data services, unless both 800 and 1900 bands are accessible. Some more links that may be of use: http://www.jl-company.com/Antenna/AmpWilson.html http://www.cellularspecialties.com/PDF%20Datasheets/CSI-610Datasheet_0905.pdf http://www.andrew.com/products/inbuilding/default.aspx Bob
Re: Route Supression Problem
Hrmm... Then care to take a stab at explaining the findings in the document that Randy referenced earlier? -danny [EMAIL PROTECTED] (Danny McPherson) writes: Dampening is done on the eBGP router where the route enters the AS, and, unless I'm mistaken, per route/path and not per prefix. So the flapping that ISP A sees from ISP B is a completely seperate thing from the flapping that ISP A sees from its customer's customer as far as the dampening algorithm is concerned. Nope. It's per-prefix. Nope. It is per-path. Pedro.
Re: Route Supression Problem
On Wed, 12 Mar 2003, Danny McPherson wrote: Dampening is done on the eBGP router where the route enters the AS, and, unless I'm mistaken, per route/path and not per prefix. So the flapping that ISP A sees from ISP B is a completely seperate thing from the flapping that ISP A sees from its customer's customer as far as the dampening algorithm is concerned. Nope. It's per-prefix. If that is the case then dampening is severely broken, because then a router that receives a prefix over two paths will lose *both* if _one_ flaps. In any case, it is done on the eBGP router receiving the prefix/route, so unless the two ISPs in question peer using the same router as they use to connect to Jack's AS, there still shouldn't be any flapping multiplication. (Hm, unless that happened inside Jack's network...?) Iljitsch
Re: Route Supression Problem
On Wed, 12 Mar 2003, Randy Bush wrote: You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. randy Better Algorithms -- http://www.kotovnik.com/~avg/flap-rfc.txt http://www.kotovnik.com/~avg/flap-rfc.ps I didn't publish that one because I wanted to compare that with penalty-based dampening on historical (pre-dampening) flap records, but then got distracted by other projects. Preliminary data (from frequency analysis) indicates that unwarranted downtime (defined as suppression after the last flap prior to entering stable state) is reduced by a factor of 3 to 4 compared with penalty-based algorithm tuned to produce the same post-dampening flap rate. --vadim
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
JC Dill [EMAIL PROTECTED] wrote: Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. With that in mind, perhaps IANA and ICANN can be persuaded to renumber into new space every time some is allocated? Or if you enjoy helpdesk staff abused by end users in their thousands, encourage the use of a .sex tld and house the root in new space. TT
Re: Route Supression Problem
Thus the application effect being talked about. Sure, I understand that. I was making a different assumption... That the sources of traffic were likely from downstream ASs, not ISP A, or even B or C, and as such, the multiplication could happen per prefix. However, without knowing the number of penalizing events, what constitutes a penalizing event, and aggressiveness of your peers suppression policies -- or the source distribution of the traffic, it's tough to tell. -danny
cw to att? issue?
Anyone else seeing an issue between cw and att somewhere near sf it looks like. I go from 4 ms, at the point tagged as the peer between cw and att and 1400 ms once I land on att. THanks
Re: Route Supression Problem
From: Iljitsch van Beijnum Nope. It's per-prefix. If that is the case then dampening is severely broken, because then a router that receives a prefix over two paths will lose *both* if _one_ flaps. Which makes me wonder what happens when one of my BGP peers is flapping and the other is holding stable with an AS prepend on it. In any case, it is done on the eBGP router receiving the prefix/route, so unless the two ISPs in question peer using the same router as they use to connect to Jack's AS, there still shouldn't be any flapping multiplication. (Hm, unless that happened inside Jack's network...?) My network is too simplistic to have flapping multiplication. The only difference between the customers routes and my own are that I do an AS prepend on all my networks going out to one of my peers so that the peer only sends customer traffic to me and serves as a last resort, while my customers routes out all peers without modification. -Jack
Re: cw to att? issue?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ATT has been having several issues over the past few days, especially with their broadband unit on the west coast to alot of central california locations where latency jumps from 20ms to 1100ms nightly. This just started a few days ago. I opened a ticket (as a customer) to their broadband division but never heard back. So, I'm not suprised. Who knows what's going on over there. It's getting pretty annoying though. Scott Granados wrote: | Anyone else seeing an issue between cw and att somewhere near sf it looks | like. | | I go from 4 ms, at the point tagged as the peer between cw and att and | 1400 ms once I land on att. | | THanks | | | | - -- Thanks, Shon Elliott Systems Engineer; OptiGate Networks, Inc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE+b6qIt49dIzGDssARAjKpAJ0XppvkSeXK3iy9+qAieTL4wWT9vACdGkGy auVFi/gTFY3Ffg1P8j9ojKs= =nUR6 -END PGP SIGNATURE-
Re: cw to att? issue?
No issues to report, probably a return path issue. It'd be easier to confirm that with a traceroute showing the latency. And you will get a timely response from [EMAIL PROTECTED], which is where this email belongs. Regards, Mark Kasten Cable Wireless Scott Granados wrote: Anyone else seeing an issue between cw and att somewhere near sf it looks like. I go from 4 ms, at the point tagged as the peer between cw and att and 1400 ms once I land on att. THanks
Re: 69/8...this sucks
On Tue, 11 Mar 2003 14:58:10 MST, Alec H. Peterson said: How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? I suspect the problem isn't the backbones that have a NOC. The problem is small mompop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name. pgp0.pgp Description: PGP signature
Re: cw to att? issue?
It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. On Wed, 12 Mar 2003, IP-GNOC wrote: No issues to report, probably a return path issue. It'd be easier to confirm that with a traceroute showing the latency. And you will get a timely response from [EMAIL PROTECTED], which is where this email belongs. Regards, Mark Kasten Cable Wireless Scott Granados wrote: Anyone else seeing an issue between cw and att somewhere near sf it looks like. I go from 4 ms, at the point tagged as the peer between cw and att and 1400 ms once I land on att. THanks
Re: 69/8...this sucks
The problem is small mompop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name. maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?
Re: 69/8...this sucks
Andy Dills wrote: On Wed, 12 Mar 2003, Randy Bush wrote: maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained? Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Filter (public, private and transit) peers or customers...? Or themselves? I've had a few customers spontaneously (ahem) come up with remarkably Rob Thomas configs (if any noun can be verbed, can any name be adjectived?) -- I usually convince them to tone down the filters a bit. The funny ones are those who've signed up for a partial table or default. Then again, I suppose you can't be too careful. Peter E. Fry
Re: 69/8...this sucks
On Wed, 12 Mar 2003, Peter E. Fry wrote: Andy Dills wrote: Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Filter (public, private and transit) peers or customers...? Or themselves? Yes. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Getting a Host Record
I'm feeling really dumb asking this, but how does one get host info out of Network Solutions WHOIS these days? I want to look up the contact info on a host. I can get the IP from the hostname and vice-versa along with the registrar, but I can't figure out how to get the full record. Nameserver queries don't seem to work on whois.networksolutions.com anymore, and the records for zones that I know use the server no longer include the NIC handle for the nameservers. How do I get the record? Or get the NIC handle to get the record through WHOIS? (And I though netsol _used to_ suck. Thank goodness ICANN is saving us all.) -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
Re: Getting a Host Record
On Wed, Mar 12, 2003 at 05:25:15PM -0800, Crist J. Clark wrote: I'm feeling really dumb asking this, but how does one get host info out of Network Solutions WHOIS these days? I want to look up the contact info on a host. I can get the IP from the hostname and vice-versa along with the registrar, but I can't figure out how to get the full record. Nameserver queries don't seem to work on whois.networksolutions.com anymore, and the records for zones that I know use the server no longer include the NIC handle for the nameservers. I usually use 'whois.crsnic.net': jazz% whois -h whois.crsnic.net ns1.dreamhost.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Server Name: NS1.DREAMHOST.COM IP Address: 66.33.206.206 Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com What's odd is that the Network Solutions whois server doesn't give out this information anymore, even for domains registered through NetSol / Verisign. jazz% whois -h whois.networksolutions.com HOST ns1.dreamhost.com [snip disclaimer] No match for host NS1.DREAMHOST.COM. This format used to work. -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Miss Rothschild wrote: On 2003-03-11-21:01:00, JC Dill [EMAIL PROTECTED] wrote: (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) Ahem. It's _MS._ Dill, thank you. Please post with a gender-specific name if you want to take offense when mis-identified. It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. That distinction has disappeared, and it is a huge revolution in society, says Michael Maccoby, an anthropologist and psychoanalyst. http://www.washingtonpost.com/ac2/wp-dyn/A137-2000Aug9?language=printer It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. How do I configure my routers and web servers for that? ObNanog: Assuming you don't work at Google, if you aren't blocking 69/8 then your network will not be harmed in any way by the implementation of this proposal. Thus you need to do nothing special at all. OTOH, if you are improperly blocking 69/8, obviously you need to fix that when you configure your routers and web servers (sic). I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more. Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here. If you don't work at Google, then this is none of your concern. p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you. If duplicate messages cluttering your inbox are causing you much grief, They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. jc [1] JC Dill is my real name. It is the name on my passport and other official documents.
Re: cw to att? issue?
On Wed, Mar 12, 2003 at 02:19:58PM -0800, Scott Granados wrote: It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. route-server.ip.att.net When in doubt, try looking at the reverse path. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: cw to att? issue?
Is there a good plac for a listing of the publically available route-servers? I only knew of the oregon one. Thanks - Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] To: Scott Granados [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 5:35 PM Subject: Re: cw to att? issue? On Wed, Mar 12, 2003 at 02:19:58PM -0800, Scott Granados wrote: It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. route-server.ip.att.net When in doubt, try looking at the reverse path. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Getting a Host Record
Which domain/host do you need record for? I can try to find info through some backdoors but even that may not work any more... And do note that system with dns hosts ips has changed as of year ago, ips are no longer needed for registered hosts (unless the domain is also the same the nameservers listed for it), dns servers must lookup proper ip of nameserver by resolving host names. And if change is needed for ip (when for host in the same domain), it is done through interface provided by the registrar that is related to that domain. As such almost all registrars no longer associate contacts with hosts but only associate hosts with their proper domains and often do not even list ip there. On Wed, 12 Mar 2003, Crist J. Clark wrote: I'm feeling really dumb asking this, but how does one get host info out of Network Solutions WHOIS these days? I want to look up the contact info on a host. I can get the IP from the hostname and vice-versa along with the registrar, but I can't figure out how to get the full record. Nameserver queries don't seem to work on whois.networksolutions.com anymore, and the records for zones that I know use the server no longer include the NIC handle for the nameservers. How do I get the record? Or get the NIC handle to get the record through WHOIS? (And I though netsol _used to_ suck. Thank goodness ICANN is saving us all.)
Re: cw to att? issue?
On Wed, 12 Mar 2003, Scott Granados wrote: Is there a good plac for a listing of the publically available route-servers? I only knew of the oregon one. http://www.traceroute.org/#Route Servers -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
gender and nanog
It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. though not offended, it does tell me a lot about the person making the assumption. and it ain't positive. but that nanog is yet another male dominated technical culture (yamdtc) should surprise no one here. on the other hand, the level of immature rudeness exhibited (remember when abha posted about the geekgirls list?) can be *extremely* embarrassing, and some folk can insist on making utter asses of themselves. but, sad to say, none of this should surprise women. not to say that women and men should not stand up against it when it occurs. we now return you to small operators trying to convince other small operators how they should run the route filters in their shops. imiho, if it is not automated by protocol, banana eaters will screw it up for sure. so, again imiho, this topic is about as likely to make progress as serious gender equity in my lifetime sigh. randy
Re: cw to att? issue?
www.traceroute.org should have some but that site hasn't been updated in ages.. These are *some* that I know including oregon: route-views.oregon-ix.net route-views2.oregon-ix.net route-server.gt.ca route-server.ip.att.net route-server.cw.net route-server.bbnplanet.net hope it helps.. -hc On Wed, 12 Mar 2003, Scott Granados wrote: Is there a good plac for a listing of the publically available route-servers? I only knew of the oregon one. Thanks - Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] To: Scott Granados [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 5:35 PM Subject: Re: cw to att? issue? On Wed, Mar 12, 2003 at 02:19:58PM -0800, Scott Granados wrote: It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. route-server.ip.att.net When in doubt, try looking at the reverse path. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JC Dill Sent: March 12, 2003 8:37 PM To: [EMAIL PROTECTED] Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks) It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: [snip] It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. I wonder if perhaps a solution would be doing something I saw a gentleman from China, IIRC, do on this list quite a while ago. He had added (Mr.) to his .sig to make it easy for people to figure out his gender. Perhaps this would be an easyish way to somewhat-subtly warn people of the correct gender? Vivien -- (Mr.) Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Wed, 12 Mar 2003, JC Dill wrote: It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. That distinction has disappeared, and it is a huge revolution in society, says Michael Maccoby, an anthropologist and psychoanalyst. Got any statistics for the actual demographic in question (NANOG)? Probably not. But if you did, they'd support the assumption that an unknown person is likely male, with extreme statistical significance. It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? Not be offended if somebody didn't know my gender? p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you. Well, as somebody who rudely runs a mailing list, you should be used to standard mailing list operating procedure. If duplicate messages cluttering your inbox are causing you much grief, They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. Except, you know he's male, and he didn't know you were female. So, you end up looking like a petty whiner who siezed upon the ability to be offended, even when there was no cause for it. Get over it. If my name was Andrea, I wouldn't be pissed if people assumed I was a woman. I'd correct them and move on. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
From: Vivien M. I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :) -Jack
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Bates Sent: March 12, 2003 9:29 PM To: [EMAIL PROTECTED] Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks) From: Vivien M. I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :) Well, I've gotten [non-serious, I hope] marriage proposals from guys on Usenet before... I wouldn't go as far as Ms. Dill and saying it's offensive, but it is annoying that whenever you call some company and they look you up in their database, they say ma'am instead of sir (or, in Ms. Dill's case, presumably the opposite), and whenever you start posting in a new forum (Usenet, mailing list, etc), you inevitably have to correct the first person who refers to you with the wrong gender pronouns, etc, which is always embarassing for both you and the person who made the mistake... That said, this is getting horribly off-topic... though perhaps we should ask whether sex mailing lists are hosted on networks that filter 69/8? :) (Yes, I know, that wasn't a good attempt at being on topic...) Vivien -- (Mr.) Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: 69/8 problem -- Would CNN care?
From: Avleen Vig Let's spin this argument on it's head for a moment and look at it from another view point: What you're facing, is opposition from neglegent and / or lazy network administrators. Going up against them is always difficult. Believe me, I know. I consider this the same view. It is difficult. My objection is to the fact that people complain concerning the increase in posts (which I am obligated to read almost all of them) while I'm trying to pull resources that I don't personally possess, ie. the ideas and abilities of NANOG participators. So, lets look at a hypothetical situation: CNN (or someone) reports that someone within 69/8 is generating most of the spam, or distributing most of the world's viruses, or something equally stupid that the mass media occassionally spurts out. Primary blocking of 69/8 is not caused from mass media. It is caused from old router configs. Mass media might be the way out. Having said that, I do block networks in 69/8 for spam and viruses. :) What do you do then? Get CNN to retract the story? That own't accomplish anything really and we all know it. Retractions aren't news. People don't notice them. This is news worthy, as it affects a service that people have grown to depend on in their daily lives. Even if it conflicts with another new story (wouldn't be the first time), it should be put out and with enough force that every day people are aware of it, which will mean some firewalls will get checked. This is not a technical problem, so technical means (centralised filtering) won't work. The idea of Centralized filtering isn't to solve the current issue, but to hopefully develop a solution that can help prevent this problem in the future. Neither is it a policy problem, people are free to filter what they like. They are allowed to, but most are filtering out of ignorance. They wouldn't be filtering if they had the clue. There's a very fine line between filtering a network out on purpose, and neglegently not removing filters when space is allocated. From some view points, they're one and the same thing. Yes, I agree. Yet, my personal goal is to have neither where my network is concerned. I work long hours, have my personal time interrupted (including vacations) to maintain my network and make it the best that I can. I work hard to please my users as well as other networks at the same time, even though their desires often conflict. It is this very reason that the 69/8 threads interest me. I am not alone in these things. As a community, we need to be proactive with these issues and not just reactive. Waiting for the customer to complain is not the ideal solution. Perhaps I'm wrong. Perhaps we don't possess the intellect to solve such problems. We can't solve the spam problem, so why should we be able to solve this? -Jack
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills [EMAIL PROTECTED] said: Not be offended if somebody didn't know my gender? Fortunately, none of the simians on the list have objected to being classified as 'banana eaters' ;) pgp0.pgp Description: PGP signature
route filtering in large networks
On Wed, 12 Mar 2003, Randy Bush wrote: we now return you to small operators trying to convince other small operators how they should run the route filters in their shops. imiho, if it is not automated by protocol, banana eaters will screw it up for sure. so, again imiho, this topic is about as likely to make progress as serious gender equity in my lifetime sigh. Randy, you've run a huge network. I have not had that opportunity, and I don't have banana eaters working for me (and I'm not sure what that phrase means exactly, but I'll assume it isn't racial). I must not understand something. How would the banana eaters screw up applying the same prefix-list outbound to all neighbors? Seems like an easy protocol to follow. I could understand the problems with applying inbound filters (unique huge filter for each neighbor), but if you're willing to localize bogon routes to the border router, without redistributing them, you get the job done. So filter announcements to every neighbor. That way, only the places with lots of administration (places that will know to update filters) will need to worry about updating filters. Then, bogon traffic only flows as far as the default route takes it, without the ACL hit. I'm not telling people that this is the cure, that this is how they should run their network. I'm asking for the big operators to tell me what's wrong with this idea. In theory, it should work, but I don't have the pragmatism that comes with running a nationwide network staffed by banana eaters. If nothing else, it seems like a worthy stopgap until the next iteration of BGP comes along to really address the trust issues. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Gender and other protocol issues
A famous Internet personality is alleged to have said, approximately, Be liberal in what you accept. Be exact in what you emit. 'Seems like this continues to be sound advice. :-) JimC
RE: Gender and other protocol issues
Speaking of Gender and Protocol, I think this whole gender bias thing can be solved by implementing an LDAP server Sorry - wrong thread... -Original Message- From: Cutler, James R [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 10:44 PM To: [EMAIL PROTECTED] Subject: Gender and other protocol issues A famous Internet personality is alleged to have said, approximately, Be liberal in what you accept. Be exact in what you emit. 'Seems like this continues to be sound advice. :-) JimC
Re: route filtering in large networks
From: Richard A Steenbergen Simple, apply a bogon list and then fail to update it. If you are not ready willing and able to keep your lists updated, you probably shouldn't have applied them in the first place. I routinely see people doing absurd things like applying ipfw bogon filters on individual servers to protect against DoS that end up costing them way more in performance than they could possibly gain from filtering the bogons. Let's keep it real folks, these filters aren't needed everywhere. You think that's bad? Try this one. Contacted network to inform them that they had an access list on a router rejecting 69/8 and that 69/8 was recently handed out, blah blah blah. Get a call back saying that they found the route for 69 and removed it. Could I please try it again. To humor said person, I tried it again and got what I expected (A). My question is, if he's running an acl with a bogon list, why does he have a route (presumably static since it was removed) for 69/8? I'm tempted to start mailing out bananas. -Jack
Re: route filtering in large networks
I must not understand something. How would the banana eaters screw up applying the same prefix-list outbound to all neighbors? Humans tend to be imprecise. Scripted actions tend to be very precise. Implementing a process by which humans manually enter configurations is prone to error and more difficult to check. Implementing a scripted, automated process that enters configurations from a text file or database is more likely to be precise and thorough. In an anecdotal case, a human going router by router to update ACL 101 is more prone to accidently skip a line in his vi list or his web list, that guides his manual logins. Another simple error that a human could make is to accidently mistakenly change cut/paste buffer. An automated computer program or script is much more likely to be precise. Notice I use the word precise above and not accurate. Humans may be more accurate in that they are intelligent enough to fix one-off problems. But when managing many many objects many network folks would value reliable precision over occasional accuracy. One can always manually find inaccuracies, and put algorithms for exception reports, of 'one-off situations' into a precise script. This is why many folks rightfully argue that change management should be scripted, and not entrusted to less experienced manual humans. There's a balance, and you can't have the Olivaws running amuch with their unintelligent precision. The automated processes must be well thought and audited by an intelligent, accurate human. -a
RE: route filtering in large networks
You think that's bad? Try this one. Contacted network to inform them that they had an access list on a router rejecting 69/8 and that 69/8 was recently handed out, blah blah blah. Get a call back saying that they found the route for 69 and removed it. Could I please try it again. To humor said person, I tried it again and got what I expected (A). My question is, if he's running an acl with a bogon list, why does he have a route (presumably static since it was removed) for 69/8? I'm tempted to start mailing out bananas. Check out http://www.cymru.com/Documents/secure-ios-template.html All of the various Bogons, including unassigned ranges, are represented with a route to null0. Mike
Re: route filtering in large networks
How would the banana eaters screw up applying the same prefix-list outbound to all neighbors? by spending [some small part of] their time configuring routers as opposed to building tools to configure routers demonstratably correctly. when fingers 'touch' routers, bad things are bound to happen sooner or later. randy
Re: route filtering in large networks
If you are not ready willing and able to keep your lists updated, you probably shouldn't have applied them in the first place. a poor but wise person who had the onerous task of managing me in the late '60s said i had a talent for stating the obvious. it was meant as a compliment. randy
Re: route filtering in large networks
From: Michael K. Smith Check out http://www.cymru.com/Documents/secure-ios-template.html All of the various Bogons, including unassigned ranges, are represented with a route to null0. Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways? -Jack
Re: route filtering in large networks
On 12 Mar 2003 at 22:59, Jack Bates wrote: Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways? It's a generic config -- note the ! Default route to the Internet [...]. Saves you some microbucks on that burstable Internet link, or maybe some of that micro-upstream-bandwidth on your ADSL when you get those spoofy pings. Hey -- you asked. I recommend it myself, on a smaller scale. (Sigh.) Your ideas are nice, but I'd have to rant all over this list to keep y'all from filtering my compelling bogon content. Peter E. Fry
Re: cw to att? issue?
Hi, Scott. ] Is there a good plac for a listing of the publically available ] route-servers? I only knew of the oregon one. I keep a list in the Secure BGP Template: http://www.cymru.com/Documents/secure-bgp-template.html I do this so that I don't forget them. :) Updates and comments are always welcome! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: route filtering in large networks
On Wed, 12 Mar 2003, Jack Bates wrote: From: Michael K. Smith Check out http://www.cymru.com/Documents/secure-ios-template.html All of the various Bogons, including unassigned ranges, are represented with a route to null0. Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways? I didn't look at the template recently, but I recall something like: route instead of acl... so allow the traffic in and kill it on the way out. Alternately, with uRPF inbound it'll kill the traffic on the inbound since the destination for the packet (source in this case) is invalid.
Re: route filtering in large networks
Hi, Jack. ] Nice, although it doesn't explain the purpose of having the routes if you ] have an acl. To keep viruses from attempting to contact bogons? To stop your ] internal network from surfing the bogon web which can't reply back anyways? Basically, yes. I'm not worried about folks web surfing 10/8. :) There are things that go wrong, however, and I firmly believe in filtering both on ingress and egress (at the edge, to be clear). This is an extra bit of protection in case something bad happens, be it malware, fat fingers, etc. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
