Anyone alive at ep.net
I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. If anyone from ep.net could email me with our allocation request, thanks are in order. Thanks ahead of time, -Chris
Re: Anyone alive at ep.net
I've been awaiting allocation of an IP from an IX that is allocated by ep.net. (assuming you are waitinng for IPv6 address range) why not get an allocation for IX from ARIN/RIPE? itojun
Re: GSR, 7600, Juniper M?, oh my!
GSRs are useless if you are doing any kind of aggregation. Their traffic shaping abilities are embarrassing. Historically yes, but no longer. The latest line of GSR cards now give them much greater capability in this area even though it was never designed as an access box. 7500 is the classic aggregator. They do the job quite well, actually. Based on cost right now, I would take 10 7500s over 1 7600 anyday. If you are just aggregating E1/T1 then I'd agree, but the minute you need DS-3/E3/STM-1/ATM/100BaseT/Gige aggregation then the 7600 is a far better choice cost wise, if only the code on it worked. The feature set for the 7600 and the roadmap is very impressive but Cisco need to spend a large part of time a: fixing the bugs in the code and b: training their people how this box works. For transit, though, I would use a Juniper - hands down. Cisco has to get their $hit together in terms of software stability one would hope it would get more stable over time but alas no. transit ? In my view the software on the GSR is very stable, in fact probably one of the most stable parts of the IOS family. I can count on one hand the number of real bugs we have for the GSR in the last 3-4 years, and two of them were security related. [which as I understand it Juniper is not ammune to either]. There are issues with the early engine 0 and engine 1 cards on the GSR so beware if buying second user cards. Also I would not underestimate the effort of going multivendor for core and access devices. There are alot of issues other than just cost when going multivendor. Regards, Neil.
Re: GSR, 7600, Juniper M?, oh my!
7500s? In 2004? Throw those things in the trash where they belong. It's always amazing to me how many people will cling to obsolete things for years just because it is what they know. Don't agree with this. For E1/T1 access these boxes are fine. Yes they are long in the tooth but they are quite capable. I wouldn't spend a huge amount of time or money trying to make them do anything else though. Even a Juniper M5 will do 16 OC3's with line rate filtering and forwarding. There are probably a dozen design considerations based on requirements you haven't described, but if you're doing primarily sonet, 7600 isn't really the way to go. Depends on what primarily sonet means. Regards, Neil.
Re: Anyone alive at ep.net
On Wed, 7 Jan 2004, Jun-ichiro itojun Hagino wrote: I've been awaiting allocation of an IP from an IX that is allocated by ep.net. why not get an allocation for IX from ARIN/RIPE? Because then he wouldn't be able to use it to communicate with anyone else at the exchange, since they'd all be in the ep.net subnet, and he'd be in a different subnet. -Bill
survey on BGP damping
*** Apology if you've read it before. I re-send this survey hoping to get *** more replies. Thanks. Hi, We are conducting a survey of BGP damping deployment and would greatly appreciate if you could take a few minutes to answer the following questions. There are a number of interesting results and various recommendations for damping settings. However, we have found only limited information on who does(does not) deploy damping and what parameter settings are selected in practice. If you are willing to participate, please send replies directly to us. We will collect the results (removing any private information regarding specific sites) and post the results to the list. Thanks! --- beichuan (1) Does your AS have BGP route flap damping turned on? * Yes * No (please skip to comments) (2) What damping parameters do you use? * Cisco Default * Juniper Default * RIPE recommendation * Customized (3) On which links do you enable damping? * To customers only * To providers * To peers * All the above (4) Comments Please tell us more such as: What kind of network are you managing (any specific names will be removed in the published study)? Why (why not) do you enable damping? If you enable damping, why did you choose your current parameters? Has your site seen specific problems that were prevented by damping (or caused by damping)? We welcome any other comments you feel are relevant. Thanks!
RE: Anyone alive at ep.net
ep.net is the neutral IP allocation agency for a significant number of exchanges world wide. We have our own IP space, however, we require an IP on the IX so we can peer with other neighbors on the exchange, like Bill said! -Chris -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:49 AM To: Jun-ichiro itojun Hagino Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net On Wed, 7 Jan 2004, Jun-ichiro itojun Hagino wrote: I've been awaiting allocation of an IP from an IX that is allocated by ep.net. why not get an allocation for IX from ARIN/RIPE? Because then he wouldn't be able to use it to communicate with anyone else at the exchange, since they'd all be in the ep.net subnet, and he'd be in a different subnet. -Bill
Re: MLPPP Problem with Cisco 7513
Richard, One bug I know of that could possibly be a match is: CSCec00268 Externally found severe defect: Resolved (R) Input drops and * throttles on PPP multilink interface fixed in 12.2(15)T9. The way to verify is to check 'sh int multilink x' and see if the interface is under throttle. Router#sh int mu 2 Multilink2 is up, line protocol is up snip Received 0 broadcasts, 0 runts, 0 giants, 0* throttles ^-- Here. If that's not it email me offline and I'll help you get it resolved. Thanks, Rodney On Tue, Jan 06, 2004 at 05:30:51PM -0800, Richard J. Sears wrote: I am hoping someone can shed some light on an interesting problem we are having - When we set up a customer for MLPPP, things tend to go well for a period of time. Then - all of a sudden - we will begin to have problems with our multilink bundles (generally only one at a time) and the only fix is to reload our 7513. This problem happens on both of our 7513 routers from time-to-time. Once we reload - the problem will stay gone for as long as several months, or in the last case only about 12 hours. Once we see the problem, it is apparent only in one direction. For example the customer can push the full capacity of their circuits to us, but they cannot pull anything above about 300k back to them on a two-T1 bundle. This is the same every single time we have the problem. We have changed multilink bundles, tried different types of switching and route caching, turning on and off fragmentation - the only thing that solves the problem is reloading the entire router. We can pull the T1s from the multilink bundle and each individual T1 works great. No line errors, no crc errors - nothing. No errors are apparent while in MLPPP mode either. No throttles or anything similar. We have had this problem in the past and it was recommended that we upgrade the code on our 7513s. We are currently running version 12.2(13)T5 on both our 7513 as well as the customers router. Upgrading the code did not solve the problem. I have been unable to locate a Cisco bug defining this type of problem for any version of their code. This particular customer's T1s are both terminated on the same VIP (we are running DMLP) but are terminated on separate PAs and hence separate CT3s. We have noticed the problem even with T1 bundles on the exact same PA and CT3. We are not doing multi-chassis DMLP. dCEF is enable on both routers, however the problem remains the same even after disable dCEF. Here are configs and router info: interface Multilink6 description Eastgate Mall (s2/1/0/8:0 and s2/0/0/12:0) [20291] ip address 207.158.1.133 255.255.255.252 no cdp enable ppp multilink ppp multilink interleave multilink-group 6 interface Serial2/0/0/12:0 description Eastgate Mall #2 no ip address encapsulation ppp no fair-queue ppp multilink multilink-group 6 interface Serial2/1/0/8:0 description Eastgate Mall #1 no ip address encapsulation ppp no fair-queue ppp multilink multilink-group 6 AR04#sh diag 2 Slot 2: Physical slot 2, ~physical slot 0xD, logical slot 2, CBus 0 Microcode Status 0x4 Master Enable, LED, WCS Loaded Board is analyzed Pending I/O Status: None EEPROM format version 1 VIP2 R5K controller, HW rev 2.02, board revision D0 Serial number: 17953368 Part number: 73-2167-05 Test history: 0x00RMA number: 00-00-00 Flags: cisco 7000 board; 7500 compatible EEPROM contents (hex): 0x20: 01 1E 02 02 01 11 F2 58 49 08 77 05 00 00 00 00 0x30: 68 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Slot database information: Flags: 0x4 Insertion time: 0x41C8 (1d08h ago) Controller Memory Size: 32 MBytes DRAM, 4096 KBytes SRAM PA Bay 0 Information: CT3 single wide PA, 1 port EEPROM format version 1 HW rev 1.00, Board revision A0 Serial number: 17814822 Part number: 73-3037-01 PA Bay 1 Information: CT3 single wide PA, 1 port EEPROM format version 1 HW rev 1.00, Board revision A0 Serial number: 09725065 Part number: 73-3037-01 --Boot log begin-- Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Wed 28-May-03 21:57 by nmasa Image text-base: 0x60010930, data-base: 0x604C AR04#sh ver Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JSV-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Wed 28-May-03 22:00 by nmasa
Re: Out of office/vacation messages
On Sat, Jan 03, 2004 at 06:58:46PM -0500, Joe Maimon wrote: Rachel K. Warren wrote: On Fri, Jan 02, 2004 at 10:32:23AM -0500, William Allen Simpson wrote: - run on Windows, Oops, I see your problem. No self-respecting network operator runs any M$W boxen as an MTA, so Templin is an imposter/troll. Sometimes you have no choice but to run a Windows mail client - it's called your company forcing you to a standard mailer. It's not something I have It has been noted by other people on NANOG that I am talking about an MUA instead of an MTA. That is correct, I got them mixed up by accident, but my argument still stands, just substitute MTA for MUA. Might I suggest posting from home on your free time, using a standardized setup that doesn't annoy others? What does this have to do with this thread? For your information, when I read and post to NANOG I actually do it from home, using MUTT as an MUA and sendmail as an MTA. I fail to see why a public forum on a public openly standardized network needs to tolerate the private policies of individual members that negatively impact others on the forum. You want to participate? Play by the rules. What are you talking about? You aren't making any sense. In short, I do not think claiming My company makes me do it is a valid defense. Frankly, your supposedly argument isn't very valid either. Thanks- Rachel -- All men whilst they are awake are in one common world; but each of them, when he is asleep, is in a world of his own. - Plutarch
remember ORBL.ORG?
If anyone has any legacy mailhubs sitting around that used to use it, better check it out. It was a harmless until yesterday, when the domain was snagged by Pool.com and parked with wildcard DNS. -mark -- Mark Jeftovic [EMAIL PROTECTED] Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237
RE: GSR, 7600, Juniper M?, oh my!
Dan Armstrong wrote: GSRs are useless if you are doing any kind of aggregation. Their traffic shaping abilities are embarrassing. Neil J. McRae Historically yes, but no longer. The latest line of GSR cards now give them much greater capability in this area even though it was never designed as an access box. There still is the issue of cost though. GSR line cards are not cheap. 7500 is the classic aggregator. They do the job quite well, actually. Based on cost right now, I would take 10 7500s over 1 7600 anyday. If you are just aggregating E1/T1 then I'd agree, but the minute you need DS-3/E3/STM-1/ATM/100BaseT/ Gige aggregation then the 7600 is a far better choice cost wise I would put 10mbps Ethernet and possibly DS3 in the same pool as E1/T1 though; this still remains in the realm of things a 7500 does fine. I'm not trying to defend the 7500 platform, it's obsolete all right. However, free is music to my ears. Michel.
RE: GSR, 7600, Juniper M?, oh my!
If you are after copper aggregation and broadband user feature support, you might also want to take a look at the Cisco1. Not sure of its POS capabilities, but depending on your density, might be cheaper $/port than the 7600. Heard mixed reports on the E-series from Juniper (software mainly, so it does depend on what you try and do with it), but if you want line rate ACLs, QoS etc, hard to go past the M-series (spec. M10i, M7i). OT: love the doilly comments on the 7500. I'll have to ask Mum to make me a few... Keith Burns Principal Network Architect ICG Telecommunications IP Ph: 303-414-5385 Cell: 303-912-3777 The dogs may bark, but the caravan rolls on -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 1:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! 7500s? In 2004? Throw those things in the trash where they belong. It's always amazing to me how many people will cling to obsolete things for years just because it is what they know. Don't agree with this. For E1/T1 access these boxes are fine. Yes they are long in the tooth but they are quite capable. I wouldn't spend a huge amount of time or money trying to make them do anything else though. Even a Juniper M5 will do 16 OC3's with line rate filtering and forwarding. There are probably a dozen design considerations based on requirements you haven't described, but if you're doing primarily sonet, 7600 isn't really the way to go. Depends on what primarily sonet means. Regards, Neil.
Re: GSR, 7600, Juniper M?, oh my!
There still is the issue of cost though. GSR line cards are not cheap. Hence my point about them not being an access router :-) I would put 10mbps Ethernet and possibly DS3 in the same pool as E1/T1 though; this still remains in the realm of things a 7500 does fine. I'm not trying to defend the 7500 platform, it's obsolete all right. However, free is music to my ears. 10meg ethernet yes, DS-3 depends on whether you own the telco side as well. Neil.
RE: GSR, 7600, Juniper M?, oh my!
On Wed, 7 Jan 2004, Michel Py wrote: not trying to defend the 7500 platform, it's obsolete all right. However, free is music to my ears. What about longer term maintenance issues? Is the 7500 not scheduled for EOL from Cisco 'soon' ? So, purchasing 7500 bits that might be dropped by 'normal' Cisco support in 1 year versus purchasing some other hardware that will be in support longer might pay out in the longer term? --- Well technically buying a used 7500 doesn't entitle you to run IOS on it, so you need to re-license the Ebay Special and that usually costs close to what a new 7500 would cost. Anyway, on to the reason for my post. I've heard conflicting reports, is a 7206 faster at packet switching than a 7507? Some people tell me it is a better router, some people tell me it isn't. Feh. -Drew
Re: GSR, 7600, Juniper M?, oh my!
On Wed, 7 Jan 2004, Neil J. McRae wrote: There still is the issue of cost though. GSR line cards are not cheap. Hence my point about them not being an access router :-) ... except, they are. 6 x DS3 cards are $750 on ebay; 4 x OC12 cards are $4k. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: GSR, 7600, Juniper M?, oh my!
not trying to defend the 7500 platform, it's obsolete all right. However, free is music to my ears. What about longer term maintenance issues? Is the 7500 not scheduled for EOL from Cisco 'soon' ? So, purchasing 7500 bits that might be dropped by 'normal' Cisco support in 1 year versus purchasing some other hardware that will be in support longer might pay out in the longer term? They recently refreshed the platform with RSP16, VIP8, and MX. It's still a viable platform for many medium size providers. I personally wouldn't use it for anything passing more than a couple hundred megs (at absolute most), but we have plenty of nodes like that. Actually, we've been seeing a trend where we are replacing 4700's with 7505/7's. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: GSR, 7600, Juniper M?, oh my!
close to what a new 7500 would cost. Anyway, on to the reason for my post. I've heard conflicting reports, is a 7206 faster at packet switching than a 7507? Some people tell me it is a better router, some people tell me it isn't. Does an apple taste better than an orange? 7206 is a fixed CPU config (hold: i know, NPE's are interchangeable, however, once you have an NPE-300 or whatever in there, thats all the CPU you are going to have in it). Another words, no matter how many PAs you shove into it, it's still a NPE-whatever driving the whole thing. On the 7500, you have RSPs and VIPs; the former performing routing protocol work, vty's, RIB's, etc., the latter doing actually packet forwarding. For instance, one of our 7507's, an RSP4 with 3 VIP2-50's, routing some ATM, DS3, ChDS3, FE, and doing some MPLS AToM: core2.sne# sho proc c CPU utilization for five seconds: 4%/2%; one minute: 12%; five minutes: 12% Most of the CPU utilization is Mr. BGP Scanner, our friend and yours. Notice the /2%, informing you that this thing is barely doing any packet forwarding. VIP-Slot0sh proc c CPU utilization for five seconds: 13%/12%; one minute: 14%; five minutes: 15% VIP-Slot1sh proc c CPU utilization for five seconds: 1%/1%; one minute: 1%; five minutes: 1% VIP-Slot4sh proc c CPU utilization for five seconds: 7%/4%; one minute: 5%; five minutes: 5% Obviously, we run dCEF, which puts the VIP's in the position of forwarding everything on their own, as evidenced by the CPU measurements. However, to answer your question, even a modestly configured 7507 with RSP4, and VIP2-50's will be substantially more capable than a 7206-NPE300. Things may change on the NPE-400 or G1, but I have no direct experience with that. PS. Regards to stability; we have SUBSTANTIAL improvements in IOS stability, especially in 12.3.5a mainline. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: GSR, 7600, Juniper M?, oh my!
Christopher L. Morrow wrote: What about longer term maintenance issues? Is the 7500 not scheduled for EOL from Cisco 'soon' ? So, purchasing 7500 bits that might be dropped by 'normal' Cisco support in 1 year versus purchasing some other hardware that will be in support longer might pay out in the longer term? See below, I'm mostly talking about no throwing away what you already have; eBay is good for spares (a router sitting in a warehouse does not need software) and line cards, no more. Long-term support: as pointed out recently, I would be more comfortable with a 7500 without support vs. a 7600 with support as of today, the reason being I already know the tricks the 7500 is going to throw at me (mostly). Drew Weaver wrote: Well technically buying a used 7500 doesn't entitle you to run IOS on it, so you need to re-license the Ebay Special and that usually costs close to what a new 7500 would cost. True, but I'm not talking about buying a new router on eBay, I'm talking about using what lots of us already have (a bunch of 7500s) that are already paid for and legally licensed. As you unrack some of the 7500s out of production, you take them out of smartnet but don't throw them away: you keep them as spares, which allows you to take the production 7500s out of the 4hour/365 smartnet to put them on support-only maintenance. That's what I call free (it's not exactly, but close): router paid for already and el-cheapo contract on it. I've heard conflicting reports, is a 7206 faster at packet switching than a 7507? Greatly depends what's inside it. Sure, if your 7507 has an RSP2 (which basically is a 3640 on a blade) and legacy (meaning, non-dcef) blades a 7206 will beat the crud out of it. However, a loaded 7206 with a low-end NPE can choke when the 7507 with an RSP16 and recent VIPs will sail smoothly. Michel.
Re: Anyone alive at ep.net
I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. really? have you tried any other contact methods to get feedback from ep.net? telephone? fax? non-broadcast email? If anyone from ep.net could email me with our allocation request, thanks are in order. not enough information presented to act on your request. Thanks ahead of time, -Chris --bill
Re: Anyone alive at ep.net
I've been awaiting allocation of an IP from an IX that is allocated by ep.net. (assuming you are waitinng for IPv6 address range) why not get an allocation for IX from ARIN/RIPE? or apnic or lacnic. they all have IPv6 space available. the costs vary though. itojun --bill
Re: Anyone alive at ep.net
On Wed, 7 Jan 2004, Jun-ichiro itojun Hagino wrote: I've been awaiting allocation of an IP from an IX that is allocated by ep.net. why not get an allocation for IX from ARIN/RIPE? Because then he wouldn't be able to use it to communicate with anyone else at the exchange, since they'd all be in the ep.net subnet, and he'd be in a different subnet. -Bill well, not entirely true, he could get everyone to migrate to his non-neutral space... :) --bill
Re: MLPPP Problem with Cisco 7513
Richard J. Sears said: We have changed multilink bundles, tried different types of switching and route caching, turning on and off fragmentation - the only thing [snip] dCEF is enable on both routers, however the problem remains the same even after disable dCEF. Your last line, I think, is rather interesting. I have a 7513 with essentially the same hardware as you (ct3, fe's, etc) and was recently doing testing with red/wred. I had read the notes about dCEF and how this changes/limits some of what one can do with red/wred; as with dCEF enabled, the queueing happens on the VIP instead of the RSP. During testing, I setup a wred config on several interfaces and everything worked fine -- while using standard CEF. Later on, I enabled dCEF and began to test (d)wred. I found the limitations on parameters were a killjoy, so I tried backing out of dCEF/dwred. Interestingly, I couldn't back out. Even if I negated all the wred commands and disabled dCEF, the 'sh int' would still report the VIP was doing all the work. After more attempts and various ideas, I just reloaded the damn thing -- it came back up with, as I had hoped, the VIP no long doing wred, but rather the RSP. So, I wonder whether or not the mlppp instability isn't due to some obscure or yet undiscovered dCEF bug and also if when you disable dCEF, it's not really getting disabled. Maybe disable dCEF -- then reload? It may also help to get more familiar with the forwarding path data takes in this scenario; I'm not familiar with cisco's mlppp enough to know if all the encapsulation and multi-link work happens rsp side or vip side. Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 12.2(13)T5, RELEASE SOFTWARE Also, instead of following 12.2, maybe try the 12.0(S) train, if you're not needing specific features in 12.2. I've surveyed several other folks recently about which version they run; 12.0 S-line seems to be the least-hated and more-stable train. It sounds like (at this point) it'd be worth trying just about anything to get the mlppp links stable. G --Tk
RE: Anyone alive at ep.net
Bill, -I emailed both email addresses listed on the ep.net website contact information. -I have not as of this email received a response to my request or that email from you -Jeff's email bounces since it's an @ep.net and that seems to be rejecting all mail from both tdstelecom.com and fdfnet.net -I see no fax/phone contact information listed on the ep.net website. If you provide them, I will use them. -The webpage the IX gave me to register for IP space contained no phone/fax contact information. -I attempted to contact your INOC-DBA line, it was not active. So yes, really. Could you please provide me with what we are missing to receive allocation. Thanks, -Chris -Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 12:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. really? have you tried any other contact methods to get feedback from ep.net? telephone? fax? non-broadcast email? If anyone from ep.net could email me with our allocation request, thanks are in order. not enough information presented to act on your request. Thanks ahead of time, -Chris --bill
Re: Anyone alive at ep.net
Bill, -I emailed both email addresses listed on the ep.net website contact information. -I have not as of this email received a response to my request or that email from you -Jeff's email bounces since it's an @ep.net and that seems to be rejecting all mail from both tdstelecom.com and fdfnet.net will get that checked out. other requests are being received and processed so there is an problem somewhere. -I see no fax/phone contact information listed on the ep.net website. If you provide them, I will use them. true. I had thought they were there. whois will tell you. for your reference: +1.310.322.8102 voice +1.310.322.8889 fax -The webpage the IX gave me to register for IP space contained no phone/fax contact information. that will be corrected. -I attempted to contact your INOC-DBA line, it was not active. office moves / not hooked back up yet. So yes, really. Could you please provide me with what we are missing to receive allocation. we have no data on which to act. Thanks, -Chris -Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 12:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. really? have you tried any other contact methods to get feedback from ep.net? telephone? fax? non-broadcast email? If anyone from ep.net could email me with our allocation request, thanks are in order. not enough information presented to act on your request. Thanks ahead of time, -Chris --bill
RE: GSR, 7600, Juniper M?, oh my!
On Wed, 7 Jan 2004, Alex Rubenstein wrote: They recently refreshed the platform with RSP16, VIP8, and MX. It's still a viable platform for many medium size providers. As an exercise see if you can determine when this 7513: http://noc.ilan.net.il/stats/ILAN-CPU/new-gp-cpu.html swapped from an RSP8 to an RSP16 in the past 2 months. I personally wouldn't use it for anything passing more than a couple hundred megs (at absolute most), but we have plenty of nodes like that. Actually, we've been seeing a trend where we are replacing 4700's with 7505/7's. Moves about 400Mb/sec. -Hank
RE: GSR, 7600, Juniper M?, oh my!
-Original Message- From: Alex Rubenstein [mailto:[EMAIL PROTECTED] On the 7500, you have RSPs and VIPs; the former performing routing protocol work, vty's, RIB's, etc., the latter doing actually packet forwarding. While this sounds great on paper, our experience has us shying away from dCEF and looking for something bigger and better... dCEF pushed the RSP processor down to about 5%, but pushed up the VIP processors to about 90-95%... VIP-Slot0sh proc c CPU utilization for five seconds: 13%/12%; one minute: 14%; five minutes: 15% I wish we could get our routers to do this... Obviously, we run dCEF, which puts the VIP's in the position of forwarding everything on their own, as evidenced by the CPU measurements. But each VIP is responsible for it's own traffic, so if a particular VIP runs most of the traffic, it has much higher CPU usage... In our case, we have a router loaded with VIP 4-50's and Enhanced ATM OC-3 adapters... Originally, we had a single OC-3 running about 120-130 Megs constant and the VIP CPU was at 90-95% To combat this, we had to put in additional OC-3 cards with additional VIPs and distribute the load... Still, high CPU is a problem .. For instance : CPU utilization for five seconds: 63%/63%; one minute: 63%; five minutes: 65% 30 second input rate 78227000 bits/sec, 17858 packets/sec 30 second output rate 47944000 bits/sec, 12778 packets/sec It seems to me that we should be able to do sooo much better... *sigh* OC-12 adapters are an option, but they are rather expensive ... However, to answer your question, even a modestly configured 7507 with RSP4, and VIP2-50's will be substantially more capable than a 7206-NPE300. Things may change on the NPE-400 or G1, but I have no direct experience with that. The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... PS. Regards to stability; we have SUBSTANTIAL improvements in IOS stability, especially in 12.3.5a mainline. Heh.. *old* Cisco code scares me enough... Bleeding edge is simply terrifying... *sigh* -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- Jason Frisvold Backbone Engineering Supervisor Penteledata
Re: GSR, 7600, Juniper M?, oh my!
hello! The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... what is huge reduction for you? we upgraded from npe-400 to npe-g1 on ubr7200 and processor usage decreased 20-30%. And we are pushing about 100Mbps traffic from GigE to cable and about 20-30Mbps from cable to GigE. -- tarko
RE: GSR, 7600, Juniper M?, oh my!
Tarko, What was your CPU utilization prior to the upgrade? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tarko Tikan Sent: Wednesday, January 07, 2004 12:55 PM To: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! hello! The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... what is huge reduction for you? we upgraded from npe-400 to npe-g1 on ubr7200 and processor usage decreased 20-30%. And we are pushing about 100Mbps traffic from GigE to cable and about 20-30Mbps from cable to GigE. -- tarko
RE: GSR, 7600, Juniper M?, oh my!
Ours dropped about 70% ... And it's been steady ever since.. we've added a large number of modems since that time as well... Look into 'no cable-arp' as well ... Basically, it prevents arp broadcasts and that also had a major impact on the cpu utilization of our CMTS's.. Jason Frisvold Backbone Engineering Supervisor Penteledata -Original Message- From: Tarko Tikan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! hello! The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... what is huge reduction for you? we upgraded from npe-400 to npe-g1 on ubr7200 and processor usage decreased 20-30%. And we are pushing about 100Mbps traffic from GigE to cable and about 20-30Mbps from cable to GigE. -- tarko
Re: GSR, 7600, Juniper M?, oh my!
On Wed, 7 Jan 2004, Florian Weimer wrote: Tom (UnitedLayer) wrote: Buying GSR's is probably the right replacement for 7500's if you want to stick with Cisco. But be careful when buying the linecards. Not all of them have comparable forwarding performance to the 7500 if you do something else than mere IP packet fowarding (e.g. ACLs or policy-based routing). Given that a GEIP in a 7500 can only do 200-300Mbps (packet load dependant), I hope the GSR can do better :) I have heard of instances where enabling inbound packet filtering or shaping on certain GigE cards would cause the cards to shutdown or reboot. I generally don't do shaping/etc on core gear, because its much easier to do it on my aggregation gear (2948G-L3/4908G-L3).
Re: Anyone alive at ep.net
-Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 12:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. --bill Ok for the NANOG folks. We found Christopher's request in the questionable spool, it was submitted less than 48 hours ago. The EP.NET turn time is listed at 96 hours. The gyrations on the EP.NET end are due to: - office relo - software upgrades (new OS) - spam mitigation processes His request will be processed in the normal window. There are still some issues w/ procmail/spamassasin tuning. --bill
Re: GSR, 7600, Juniper M?, oh my!
hello! What was your CPU utilization prior to the upgrade? Like always before the upgrade - 95% :) Currently on npe-g1 it's 80% on peak times with traffic numbers I mentioned before and 4500 online modems, 3000 cpe's -- tarko
RE: Anyone alive at ep.net
For the record, that is simply NOT true: From: [EMAIL PROTECTED] Date: December 30, 2003 11:30:57 AM CST To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: nota.dal.net REGISTRATION TYPE (N)ew (M)odify (D)elete..:N Site for connection: NOTA It was requested in 12/30/2003. Well past the 96 hour window. -Chris -Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 3:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net -Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 12:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. --bill Ok for the NANOG folks. We found Christopher's request in the questionable spool, it was submitted less than 48 hours ago. The EP.NET turn time is listed at 96 hours. The gyrations on the EP.NET end are due to: - office relo - software upgrades (new OS) - spam mitigation processes His request will be processed in the normal window. There are still some issues w/ procmail/spamassasin tuning. --bill
Re: GSR, 7600, Juniper M?, oh my!
What about longer term maintenance issues? Is the 7500 not scheduled for EOL from Cisco 'soon' ? So, purchasing 7500 bits that might be dropped by 'normal' Cisco support in 1 year versus purchasing some other hardware that will be in support longer might pay out in the longer term? Write an email-responder at [EMAIL PROTECTED] which replies with Please upgrade to latest IOS first. Version 2.0 could give you ticket numbers and optionally request you to fill templates full of irrelevant information. Hardware is probably cheaper on eBay than the maintenance fees anyway. Pete
Re: Anyone alive at ep.net
I think we can all agree, that we all still love you :) Ok for the NANOG folks. We found Christopher's request in the questionable spool, it was submitted less than 48 hours ago. The EP.NET turn time is listed at 96 hours. The gyrations on the EP.NET end are due to: - office relo - software upgrades (new OS) - spam mitigation processes His request will be processed in the normal window. There are still some issues w/ procmail/spamassasin tuning. --bill -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: Anyone alive at ep.net
bill wrote: -Original Message- From: bill [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 12:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Anyone alive at ep.net I've been awaiting allocation of an IP from an IX that is allocated by ep.net. I've been recieving connection refused form the mailserver from several domains for over a week. --bill Ok for the NANOG folks. We found Christopher's request in the questionable spool, it was submitted less than 48 hours ago. The EP.NET turn time is listed at 96 hours. The gyrations on the EP.NET end are due to: - office relo - software upgrades (new OS) - spam mitigation processes His request will be processed in the normal window. There are still some issues w/ procmail/spamassasin tuning. Interesting to compare this with the Wed Jan 07 13:27:16 2004 response.
Upcoming change to SOA values in .com and .net zones
VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. The current serial number format is MMDDNN. (The zones are generated twice per day, so NN is usually either 00 or 01.) The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1 January 1970.) For example, a zone published on 9 February 2004 might have serial number 1076370400. The .com and .net zones will still be generated twice per day, but this serial number format change is in preparation for potentially more frequent updates to these zones. This Perl invocation converts a new-format serial number into a meaningful date: $ perl -e 'print scalar localtime 1076370400' At the same time, we will also change the minimum value in the .com and .net SOA records from its current value of 86400 seconds (one day) to 900 seconds (15 minutes). This change brings this value in line with the widely implemented negative caching semantics defined in Section 4 of RFC 2308. There should be no end-user impact resulting from these changes (though it's conceivable that some people have processes that rely on the semantics of the .com/.net serial number.) But because these zones are widely used and closely watched, we want to let the Internet community know about the changes in advance. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: GSR, 7600, Juniper M?, oh my!
If only dCEF wasn't phuqed in so many versions of the IOS. life would be wonderful. We had to turn dCEF off and just run plain old ip cef on our 7513 under 12.2.19a The RSP4 CPU spikes up to 80% then back down then UP and down... weird. Jason Frisvold wrote: -Original Message- From: Alex Rubenstein [mailto:[EMAIL PROTECTED] On the 7500, you have RSPs and VIPs; the former performing routing protocol work, vty's, RIB's, etc., the latter doing actually packet forwarding. While this sounds great on paper, our experience has us shying away from dCEF and looking for something bigger and better... dCEF pushed the RSP processor down to about 5%, but pushed up the VIP processors to about 90-95%... VIP-Slot0sh proc c CPU utilization for five seconds: 13%/12%; one minute: 14%; five minutes: 15% I wish we could get our routers to do this... Obviously, we run dCEF, which puts the VIP's in the position of forwarding everything on their own, as evidenced by the CPU measurements. But each VIP is responsible for it's own traffic, so if a particular VIP runs most of the traffic, it has much higher CPU usage... In our case, we have a router loaded with VIP 4-50's and Enhanced ATM OC-3 adapters... Originally, we had a single OC-3 running about 120-130 Megs constant and the VIP CPU was at 90-95% To combat this, we had to put in additional OC-3 cards with additional VIPs and distribute the load... Still, high CPU is a problem .. For instance : CPU utilization for five seconds: 63%/63%; one minute: 63%; five minutes: 65% 30 second input rate 78227000 bits/sec, 17858 packets/sec 30 second output rate 47944000 bits/sec, 12778 packets/sec It seems to me that we should be able to do sooo much better... *sigh* OC-12 adapters are an option, but they are rather expensive ... However, to answer your question, even a modestly configured 7507 with RSP4, and VIP2-50's will be substantially more capable than a 7206-NPE300. Things may change on the NPE-400 or G1, but I have no direct experience with that. The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... PS. Regards to stability; we have SUBSTANTIAL improvements in IOS stability, especially in 12.3.5a mainline. Heh.. *old* Cisco code scares me enough... Bleeding edge is simply terrifying... *sigh* -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- Jason Frisvold Backbone Engineering Supervisor Penteledata
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 05:46:23PM -0500, Matt Larson wrote: The current serial number format is MMDDNN. (The zones are generated twice per day, so NN is usually either 00 or 01.) The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1 January 1970.) For example, a zone published on 9 February 2004 might have serial number 1076370400. The .com and .net zones will still be generated twice per day, but this serial number format change is in preparation for potentially more frequent updates to these zones. stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Upcoming change to SOA values in .com and .net zones
Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. The current serial number format is MMDDNN. (The zones are generated twice per day, so NN is usually either 00 or 01.) The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1 January 1970.) For example, a zone published on 9 February 2004 might have serial number 1076370400. The .com and .net zones will still be generated twice per day, but this serial number format change is in preparation for potentially more frequent updates to these zones. Agghh! The y2038 bug! -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Anyone alive at ep.net
hey folk, lighten up. bill does this on his own time and for a pittance. if an exchange point wants professional level service, well they can get their address space from an rir and run the allocation service themselves. my guess is that bill will soon look inexpensive and responsive. a private whine to him usually gets a response. after all, being a whiner himself, turnabout is fair play. :-) as to the question of whether bill is alive, as he is a deadhead, i guess that's up for grabs. :-) randy
Re: Upcoming change to SOA values in .com and .net zones
Frank Louwers wrote: stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Are you suggesting Yet Another Carefully Thought Out Change? Well, it _is_ the first one this year.
Re: Upcoming change to SOA values in .com and .net zones
On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | generated twice per day, so NN is usually either 00 or 01.) | January 1970.) For example, a zone published on 9 February 2004 might | have serial number 1076370400. The .com and .net zones will still | be generated twice per day, but this serial number format change is in | preparation for potentially more frequent updates to these zones. | stuid question Yup! | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! -- Richard
Re: Anyone alive at ep.net
On Wed, Jan 07, 2004 at 04:30:52PM -0600, Laurence F. Sheldon, Jr. wrote: Interesting to compare this with the Wed Jan 07 13:27:16 2004 response. FWIW: The last 2 two requests I put into Bill were done in 24 hours. The most recent was about a week ago. -- Steve Rubin / AE6CH / Phone: (408)406-1308 Email: [EMAIL PROTECTED] / N57DL / http://www.tch.org/~ser/
Re: Upcoming change to SOA values in .com and .net zones
On Wed, 7 Jan 2004, Richard D G Cox wrote: On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | stuid question Yup! | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! I think what Frank is asking is a valid question. The way BIND/etc determine when a new zone file has been issued is by seeing if it has a higher SN than the currently caches zone. Frank's question is that when view simply as 10 digit integers (which is how BIND uses them) 2004010801 is a larger integer than 1076370400. This might cause problems with cached zones and other such staleness, so it does seem a valid concern. -Scott --- Scott Call Router Geek, ATGi, home of $6.95 Prime Rib I make the world a better place, I boycott Wal-Mart
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 11:17:58PM +, Richard D G Cox wrote: | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! Don't they use MMDDNN now? So today's version whould be 2004010801. AFAIK, 1076370400 is actually less then 2004010801... I know there are ways to trick nameservers in believing less is more, but that requires at least 2 changes, and I don't know if that is actually RFC-compliant behaviour... Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Upcoming change to SOA values in .com and .net zones
In message [EMAIL PROTECTED], Richard D G Cox writes: On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | generated twice per day, so NN is usually either 00 or 01.) | January 1970.) For example, a zone published on 9 February 2004 might | have serial number 1076370400. The .com and .net zones will still | be generated twice per day, but this serial number format change is in | preparation for potentially more frequent updates to these zones. | stuid question Yup! | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! Now I'm very confused -- bc says that it is... (Well, I used 2004010700, which is what I get for the current SOA.) --Steve Bellovin, http://www.research.att.com/~smb
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 11:34:46PM +, Maarten Van Horenbeeck wrote: Hi Frank, Dag Maarten, stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? This doesn't apply here. It is perfectly possible to decrease the value of your serial number without any consequences for the DNS slave/master zone transfers, if you adhere to the procedures put forward in RFC 1912 (section 3.1). The fact that the newly introduced serial is lower will thus not have any consequences from this perspective. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? Oh, wait, right, they don't care if they break stuff... Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
RE: Upcoming change to SOA values in .com and .net zones
On 7 Jan 2004 @ 15:25 PST Richard DG Cox wrote: |On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | generated twice per day, so NN is usually either 00 or 01.) | January 1970.) For example, a zone published on 9 February 2004 might | have serial number 1076370400. The .com and .net zones will still | be generated twice per day, but this serial number format change is in | preparation for potentially more frequent updates to these zones. | stuid question Yup! | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! Um, isn't the serial number in a zone file read in by BIND as a standard integer? If so, then 2004010101 (date format serial) would be 1076370400 (UTC serial number) when compared wouldn't it as they are both 10 digit integers.? /Alex K.
Re: Upcoming change to SOA values in .com and .net zones
On 1/7/04 6:31 PM, Frank Louwers [EMAIL PROTECTED] wrote: Don't they use MMDDNN now? So today's version whould be 2004010801. AFAIK, 1076370400 is actually less then 2004010801... I know there are ways to trick nameservers in believing less is more, but that requires at least 2 changes, and I don't know if that is actually RFC-compliant behaviour... Remember this is Verisign we're talking about, RFC's need not apply. More notably RFC1912 which recommends the MMDDnn format. If CTO at Verisign's head splits open and a UFO should fly out, I want you and everyone on this list to have expected it. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Never trust a program unless you have the source.
Re: Upcoming change to SOA values in .com and .net zones
Don't they use MMDDNN now? So today's version whould be 2004010801. AFAIK, 1076370400 is actually less then 2004010801... I know there are ways to trick nameservers in believing less is more, but that requires at least 2 changes, and I don't know if that is actually RFC-compliant behaviour... maybe someone would like to read rfc 2182 section 7 randy
Re: Upcoming change to SOA values in .com and .net zones
Go read RFC 1982. They can do it that way without any real trouble as long as all of the secondary (B-M) servers are tweaked. Check out section 7 in particular. --- Phil On Thu, 8 Jan 2004, Frank Louwers wrote: On Wed, Jan 07, 2004 at 11:17:58PM +, Richard D G Cox wrote: | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! Don't they use MMDDNN now? So today's version whould be 2004010801. AFAIK, 1076370400 is actually less then 2004010801... I know there are ways to trick nameservers in believing less is more, but that requires at least 2 changes, and I don't know if that is actually RFC-compliant behaviour... Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 04:08:01PM -0800, Philip J. Nesser II wrote: Go read RFC 1982. They can do it that way without any real trouble as long as all of the secondary (B-M) servers are tweaked. Check out section 7 in particular. I know, but: - they didn't mention it - are all dnsserver rfc compliant? Vriendelijke groeten, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Upcoming change to SOA values in .com and .net zones
On Wed, 7 Jan 2004, Robert Blayzor wrote: On 1/7/04 6:31 PM, Frank Louwers [EMAIL PROTECTED] wrote: Don't they use MMDDNN now? So today's version whould be 2004010801. AFAIK, 1076370400 is actually less then 2004010801... I know there are ways to trick nameservers in believing less is more, but that requires at least 2 changes, and I don't know if that is actually RFC-compliant behaviour... Remember this is Verisign we're talking about, RFC's need not apply. More notably RFC1912 which recommends the MMDDnn format. If CTO at Verisign's head splits open and a UFO should fly out, I want you and everyone on this list to have expected it. Considering that using the MMDDnn format would still permit them 100 updates per day (every 15 minutes or so) you'd think they'd stay with the RFC. nah *grumble*
Re: Upcoming change to SOA values in .com and .net zones
Frank Louwers wrote: On Wed, Jan 07, 2004 at 11:34:46PM +, Maarten Van Horenbeeck wrote: Hi Frank, Dag Maarten, stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? This doesn't apply here. It is perfectly possible to decrease the value of your serial number without any consequences for the DNS slave/master zone transfers, if you adhere to the procedures put forward in RFC 1912 (section 3.1). The fact that the newly introduced serial is lower will thus not have any consequences from this perspective. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? Oh, wait, right, they don't care if they break stuff... Since I am currently unemployed I guess it is only as they say of academic interest to me, but I don't see why it doesn't break it, and for functionally all of time.
Re: Upcoming change to SOA values in .com and .net zones
Go read RFC 1982. They can do it that way without any real trouble as long as all of the secondary (B-M) servers are tweaked. Check out section 7 in particular. I know, but: - they didn't mention it the number of things they did not mention is O(aleph null), perhaps you are supposed to know some of them. - are all dnsserver rfc compliant? maybe you should take care of yours and let verisign take care of theirs. randy, who is enough of a klutz that he does not have to constantly search for others to blame
Re: Upcoming change to SOA values in .com and .net zones
Alexander Kiwerski wrote: On 7 Jan 2004 @ 15:25 PST Richard DG Cox wrote: |On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | generated twice per day, so NN is usually either 00 or 01.) | January 1970.) For example, a zone published on 9 February 2004 might | have serial number 1076370400. The .com and .net zones will still | be generated twice per day, but this serial number format change is in | preparation for potentially more frequent updates to these zones. | stuid question Yup! | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! Um, isn't the serial number in a zone file read in by BIND as a standard integer? If so, then 2004010101 (date format serial) would be 1076370400 (UTC serial number) when compared wouldn't it as they are both 10 digit integers.? And from the stupid question file, is 1912 a standard? (RFC Editor says it is Informational.
Re: Upcoming change to SOA values in .com and .net zones
Hi Frank, Thanks for your reply. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? The serial should not be of any importance except to the .com .net slave nameservers. To my knowledge, these are all managed by Verisign, so this should just be a purely internal operation. I really don't see the problems here most of you are referring to. Oh, wait, right, they don't care if they break stuff... I believe they have a pretty good business case for keeping it in a working state. Best regards, Maarten -- Maarten Van Horenbeeck [EMAIL PROTECTED]
Re: Upcoming change to SOA values in .com and .net zones
Hi Frank, Thanks for your reply. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? The serial should not be of any importance except to the .com .net slave nameservers. To my knowledge, these are all managed by Verisign, so this should just be a purely internal operation. I really don't see the problems here most of you are referring to. Oh, wait, right, they don't care if they break stuff... I believe they have a pretty good business case for keeping it in a working state. Best regards, Maarten -- Maarten Van Horenbeeck [EMAIL PROTECTED]
Re: Upcoming change to SOA values in .com and .net zones
At Wed, 7 Jan 2004 17:46:23 -0500, Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. [snip] But because these zones are widely used and closely watched, we want to let the Internet community know about the changes in advance. Matt, was it not possible for Verisign to give more than 30 hours notice of these changes? This is an Internet-wide change that will very likely break some systems somewhere. Surely more notice would have been reasonable. The notice actually given is so short as to be almost worthless. It might have raised Verisign's moral stock around here if more notice had been given, or even some consultation issued. As it is, Verisign seem to have moved in a way that, yet again, is likely to convince the community of Verisign's apparent arrogance and contempt towards the rest of us. Sad.
Re: Upcoming change to SOA values in .com and .net zones
On 7 Jan 2004, at 17:46, Matt Larson wrote: There should be no end-user impact resulting from these changes (though it's conceivable that some people have processes that rely on the semantics of the .com/.net serial number.) But because these zones are widely used and closely watched, we want to let the Internet community know about the changes in advance. I didn't notice anybody saying thank you for doing the right thing by announcing the change amongst the flurry of jerking knees. So, thank you for doing the right thing. Good luck with the maintenance. Joe
Re: Upcoming change to SOA values in .com and .net zones
On Thu, 8 Jan 2004, Ian Mason wrote: At Wed, 7 Jan 2004 17:46:23 -0500, Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. [snip] Matt, was it not possible for Verisign to give more than 30 hours notice of ^ these changes? This is an Internet-wide change that will very likely break some systems somewhere. Surely more notice would have been reasonable. I'd say more than 30 days is enough for what amounts to a trivial change that really only affects their slave name servers. Jim -- See what ISP-Planet is saying about us! http://isp-planet.com/services/wholesalers/flexpop.html __ Jim Dawson [EMAIL PROTECTED] Flexpop/Navi.Nethttp://www.flexpop.net 618 NW Glisan St. Ste. 101 v. +1.503.517.8866 Portland, Or 97209 USA f. +1.503.517.8868 ~~
Re: Upcoming change to SOA values in .com and .net zones
Frank, I normally keep quiet on these lists, enough people post without me doing it. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? Can you explain how this can plausibly break the zone because others use non compliant servers? All of the servers, both secondary and primary, are run by VeriSign. They know what Server software they are running. They control each of those servers, so why are people getting so vocal? I enjoy giving Matt grief as much as anyone does :) but I'm not sure why people are hassling him on this. To echo Joe's e-mail...thanks for the update Matt. JC Oh, wait, right, they don't care if they break stuff...
Re: Upcoming change to SOA values in .com and .net zones
VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. Matt, was it not possible for Verisign to give more than 30 hours notice of these changes? This is an Internet-wide change that will very likely break some systems somewhere. Surely more notice would have been reasonable. If you reread the original mail, they gave us 32 days of notice. The change will not be happening until February 9. Thanks, Adam Debus Network Engineer, ReachONE Internet [EMAIL PROTECTED]
Re: Upcoming change to SOA values in .com and .net zones
There should be no end-user impact resulting from these changes ... I believe there have been 26 (opps, now 27) responses to this announcement in the last 2 hours 45 minutes, that's about one response every 6 minutes. Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-) Martin
Re: Upcoming change to SOA values in .com and .net zones
Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-) The only impact is to our mailboxes wrt messages from people who do not fully grok the (non)issue.
Cox Dns Admins Needed
Hello Need to speak to Cox Dns Admins if they can contact me off the list having dns cache issue with there system [EMAIL PROTECTED] frankie gravato senior network and systems admin Slingo Inc.
RE: GSR, 7600, Juniper M?, oh my!
On Wed, 7 Jan 2004, Michel Py wrote: I've heard conflicting reports, is a 7206 faster at packet switching than a 7507? Greatly depends what's inside it. Sure, if your 7507 has an RSP2 (which basically is a 3640 on a blade) and legacy (meaning, non-dcef) blades a 7206 will beat the crud out of it. However, a loaded 7206 with a low-end NPE can choke when the 7507 with an RSP16 and recent VIPs will sail smoothly. Even comparing a VXR with NPE300 to a 7500 with RSP4 and VIP2-50's, the 7206 will melt down and cease functioning properly on traffic levels the 7500 handles without breaking a sweat. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: GSR, 7600, Juniper M?, oh my!
Jon Lewis wrote: Even comparing a VXR with NPE300 to a 7500 with RSP4 and VIP2-50's, the 7206 will melt down and cease functioning properly on traffic levels the 7500 handles without breaking a sweat. Interestingly enough, the eBay prices reflect this: anything below an RSP4 or a VIP2-50 is useless junk good only for home or lab; recently bought a CX-EIP2 for $0.99 and a VIP2-40 for $50. CX-FSIPs and RSP2s go for peanuts too. However, a VIP2-50 or an RSP4 still go for 500 bucks a pop, which means they are still worthy of a production environment. As mentioned before, this is comparing apples and oranges anyway. Although this is overly simplified, the bottom line is that the NPE in a 7206 needs to do the job of the RSP _and_ 3 VIPs; no wonder why it will melt. Michel.
Re: Upcoming change to SOA values in .com and .net zones
--On Wednesday, January 7, 2004 23:17 + Richard D G Cox [EMAIL PROTECTED] wrote: On 7 Jan 2004 23:02 UTC Frank Louwers [EMAIL PROTECTED] wrote: | generated twice per day, so NN is usually either 00 or 01.) | January 1970.) For example, a zone published on 9 February 2004 might | have serial number 1076370400. The .com and .net zones will still | be generated twice per day, but this serial number format change is in | preparation for potentially more frequent updates to these zones. | stuid question Yup! Nope. | but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Nope! Actually, YES... The new format will be the UTC time at the moment of zone generation encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! Right, but, the _OLD_ format is. Therefore, the old zone file prior to the conversion will be SN 2004020800 through 2004020901. After the change, the SN will be in the range 1076284800 through 1076371200 inclusive. This complete range is less than 2004020800, so, the serial number will, indeed, be going backwards at the time of the change. This should only matter to things doing automated zone transfers and a forced manual zone transfer should solve the problem. Presumably, the responsible TLD operators are being coordinated with to take the necessary steps. Anyone else doing zone transfers of COM and NET has now been warned and should take appropriate action. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgp0.pgp Description: PGP signature
Re: Anyone alive at ep.net
my guess is that bill will soon look inexpensive and responsive. cheap but not free. :) a private whine to him usually gets a response. after all, being a whiner himself, turnabout is fair play. :-) amen. as to the question of whether bill is alive, as he is a deadhead, i guess that's up for grabs. :-) closing of winterland - passing time on the WDC/LAX run. randy --bill
Re: Anyone alive at ep.net
Interesting to compare this with the Wed Jan 07 13:27:16 2004 response. FWIW: The last 2 two requests I put into Bill were done in 24 hours. The most recent was about a week ago. Steve Rubin Ok... do folks really want this automated? I've always been a fan of humans doing the validation checks... cuts down on hijacking :) But if y'all are so impatient that you -must- have it -RIGHT NOW-, then I guess a little (more) programing might be worth it. Feedback to me and not the list please. --bill
Re: Upcoming change to SOA values in .com and .net zones
At Wed, 7 Jan 2004 17:46:23 -0500, Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. Matt, was it not possible for Verisign to give more than 30 hours notice of yo. Ian. 07jan == announcement 09feb == change to be implemented. not 30 hours, 30 days. --bill
Re: Upcoming change to SOA values in .com and .net zones
On Wed, 7 Jan 2004, Laurence F. Sheldon, Jr. wrote: Frank Louwers wrote: stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? Are you suggesting Yet Another Carefully Thought Out Change? And don't forget - after much public discussion :-) Well, it _is_ the first one this year. Hank Nussbacher
Re: Upcoming change to SOA values in .com and .net zones
| but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? yup. ... The way BIND/etc determine when a new zone file has been issued is by seeing if it has a higher SN than the currently caches zone. Frank's question is that when view simply as 10 digit integers (which is how BIND uses them) 2004010801 is a larger integer than 1076370400. yup. This might cause problems with cached zones and other such staleness, so it does seem a valid concern. it'll be fine. this protocol detail only matters between master and slave servers having an AXFR or IXFR relationship. since verisign runs all of the authority servers for COM and NET, they can manage the serial number rollback as a strictly internal matter. it's only if the master is run by one party and the slave(s) are run by other parties that serial number arithmetic comes into play. since these servers are all run by one party (that is, verisign itself), they can work privately to ensure that less does not mean backward in this transition. in the past, when COM and NET were served by the root name servers, verisign would have had to coordinate a change like this according to the rules of DNS, implementation-specific rules of BIND and whatever else was running then, and the group's coordination and monitoring rules. those days are gone. verisign isn't doing anything wrong in this change, and it's probably going to work out just fine. -- Paul Vixie
Re: GSR, 7600, Juniper M?, oh my!
Many interesting network solutions that have to be dismissed outright because of IOS limitations, weaknesses or bugs can be easily expressed in newer systems, not just JUNOS. Example, please. (Agree with Jiniper OS for x86 - many people avoid Juniper because do not know it).
