Re: Why choose 120 volts?
It's worth noting that despite higher voltages here there aren't more deaths or injuries - but maybe it's because people take it more seriously. Admittedly no one I know is nuts enough to use body parts for liveness testing. (sorry for being kinda late in this discussion) I've never felt the urge to do so either, maybe I'm just a wimp. ;-) But here is a something I've heared from people who do/have or know people who do have. And usually they are people with a degree in the field of electronics: use the back of the hand don't grap wires, when current passes through your body, muscles contract and you don't want to hold on to it when those muscles make a fist or more that arm towards your body. You just want to touch it lightly. Just to make things clear, I am NOT going to suggest you should do so, just telling you what I think I heared.
RE: Why choose 120 volts?
AC Grabs, DC Pushes. And for the record, I am confident this is the longest thread in the history of this list lol. Note to self, consult nanog on facility power when building next datacenter. *laugh* //warren Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile -Original Message- From: Leen Besselink [mailto:l...@consolejunkie.net] Sent: Thursday, May 28, 2009 12:05 AM Cc: nanog@nanog.org Subject: Re: Why choose 120 volts? It's worth noting that despite higher voltages here there aren't more deaths or injuries - but maybe it's because people take it more seriously. Admittedly no one I know is nuts enough to use body parts for liveness testing. (sorry for being kinda late in this discussion) I've never felt the urge to do so either, maybe I'm just a wimp. ;-) But here is a something I've heared from people who do/have or know people who do have. And usually they are people with a degree in the field of electronics: use the back of the hand don't grap wires, when current passes through your body, muscles contract and you don't want to hold on to it when those muscles make a fist or more that arm towards your body. You just want to touch it lightly. Just to make things clear, I am NOT going to suggest you should do so, just telling you what I think I heared.
Re: MX Record Theories
On Wed, 27 May 2009 09:48:39 -0400, gb10hkzo-na...@yahoo.co.uk wrote: Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long records such as fc00:836b:4917::a180:4179. You do realize DNS queries aren't passing around addresses in ASCII? 3 additional bytes per address isn't going to break the bank. I think you might have missed the point of my post. It was a tounge in cheek reply to the poster who suggested bad things happen if the DNS message size exceeds 512 bytes. He was commenting about AOL's MX records which currently weigh in at 507 bytes. Therefore if we were to hypothesise that the world ends at 512 bytes, then companies doing things the way AOL does, but using IPv6 addresses rather than IPv4 addresses for their MX records could run into problems. Hope that clarifies :)
Re: Why choose 120 volts?
Warren Bailey wrote: AC Grabs, DC Pushes. And for the record, I am confident this is the longest thread in the history of this list lol. Note to self, consult nanog on facility power when building next datacenter. *laugh* Yeah, my fault for starting it. ;) I was really just curious how many people in the US use high voltages or stick with low voltage (in the form of 120 AC or even lower DC). The feeling I'm getting is that some are comfortable with it and use high voltages, but there's enough confusion because unlike other countries, over 120 is relatively uncommon. ~Seth
navog?
Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David
Re: navog?
On May 28, 2009, at 9:03 PM, david hiers wrote: Is anyone aware of a voip-focused group similar to nanog? VOIPSA are focused on VoIP, mainly around security: http://www.voipsa.org/ --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton
Re: navog?
david hiers wrote: Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David Would kind of be difficult to maintain such a group. Which level of VoIP are you talking about, the carrier end, the engineer end. Think about that for a moment. For the most part, for issues regarding connectivity, VoIP is no different than email is. Networks will be networks, VoIP will go down, life goes on. Resolution can be found either directly through your vendor/carrier or you can get a best guesstimate of an outage from the outages list or someone here shooting off a Are Cogent and Level3 chest thumping again? message. On the other hand, I don't know that I'd want to see a multitude of messages from someone saying My trixbox dialplan doesn't work! or, (broken english purposely inserted) Why my Cisco Call Manager is tell me to partition! I does not want to format my disk! Please is you help! There are lists out there but each has its pros and cons. VoIPSA (VoIP Security) Cisco VoIP - for Cisco related telephony, Digium mailing lists, etc. Something akin to NANOG for VoIP would quickly become filled with WTH is he/she saying like messages. Sadly, most of my cisco-voip and asterisk-users mail has been ending up in the trash via filter. I wonder if my email client knows something I don't. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x5CCD6B5E
Re: navog?
On May 28, 2009, at 10:16 AM, J. Oquendo wrote: david hiers wrote: Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David On the other hand, I don't know that I'd want to see a multitude of messages from someone saying My trixbox dialplan doesn't work! or, (broken english purposely inserted) Why my Cisco Call Manager is tell me to partition! Actually, there is a quite active cisco-voip list over on puck that discusses exactly the CM issues you refer to. (I diverted everyone to that list to keep it off c-nsp and it seems to have grown since). - Jared http://puck.nether.net/mailman/listinfo/cisco-voip
Re: navog?
Jared Mauch wrote: On May 28, 2009, at 10:16 AM, J. Oquendo wrote: david hiers wrote: Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David On the other hand, I don't know that I'd want to see a multitude of messages from someone saying My trixbox dialplan doesn't work! or, (broken english purposely inserted) Why my Cisco Call Manager is tell me to partition! Actually, there is a quite active cisco-voip list over on puck that discusses exactly the CM issues you refer to. (I diverted everyone to that list to keep it off c-nsp and it seems to have grown since). - Jared http://puck.nether.net/mailman/listinfo/cisco-voip (removed cc's to avoid sending dupes) Agreed, I browse through some of the stuff there and indeed it works for cisco telephony matters. Cisco staff has provided some really good guidance on matters there, as have Digium staffers for Asterisk's mailing list. But I can't really envision an all inclusive VoIP list with regards to the carrier end, equipment end, programming end, etc. Heaven knows I would have like to discuss Nortel and Avaya matters countless times but then those conversations would have actually ended up shifting towards SIP in which to a degree, they wouldn't have even had anything to do with the vendors at all. So I view it as a tough call. Anyhow, perhaps links should be included: http://voipsa.org/VOIPSEC/ (VoIPSA - VoIP Security related) http://puck.nether.net/mailman/listinfo/cisco-voip (Cisco VoIP related) http://lists.digium.com/mailman/listinfo/asterisk-users (Asterisk Users) http://groups.yahoo.com/group/sip-config (SIP Config (mainly spam now)) http://sipforum.org/pipermail/discussion/index.html (SIP forum) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x5CCD6B5E
RE: Why choose 120 volts?
I was referring to, when a 120v device is attached to the 5-15 end of the cord. On the inside of these grounded devices I often find that the neutral is tied to ground. So in the case of the c14 being connected to a 240v PDU when I 120v device is connected it will ground one of the load lines. And yes, voltage will drop while current spikes, thus tripping the breaker. -Original Message- From: Pete Templin [mailto:peteli...@templin.org] Sent: Thursday, May 28, 2009 10:39 AM To: Dave Larter Cc: nanog@nanog.org Subject: Re: Why choose 120 volts? Dave Larter wrote: Seems like if the c14 was connected to a 240v PDU the 5-15 would deliver 240v to the equipment, arc/pop tripping the breaker on the PDU as soon as it is connected killing power to everything on that PDU. Or am I missing something? If you plug a PDU into a service that's higher voltage than expected, why would the PDU circuit breaker trip? That breaker is measuring current, AFAICT, though in the end it might be measuring power. Regardless, it isn't measuring voltage, because that isn't constant (it's AC, after all) and is likely to drop under a short circuit, not skyrocket like the current will. pt
Re: Why choose 120 volts?
Dave Larter wrote: I was referring to, when a 120v device is attached to the 5-15 end of the cord. On the inside of these grounded devices I often find that the neutral is tied to ground. Often??? Name one device designed that way. And please tell us how well that device works when you plug it in to a GFCI-protected outlet in your kitchen. I believe that you are very mistaken. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: MX Record Theories
Not entirely on subject but I thought that allowing DNS queries to occur via TCP is mission critical for simple mail routing. We ran across this back in the day at @Home Network. Firewall rules were changed to not allow port 53 TCP. This severely affected sending mail to large distribution lists. Here is what we found and forgive me if I don't go into too much detail as it was almost 10 years a go. If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. DNS by default starts with UDP which has a limit to the datagram size (64bit). A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. -BobbyJim On Tue, May 26, 2009 at 2:01 PM, valdis.kletni...@vt.edu wrote: On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-na...@yahoo.co.uk said: would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? The trick here is that it isn't always *exactly* the same goal. There's multiple mail system architectures and design philosophies. One often overlooked but very important design point for the *large* providers: % dig aol.com mx ;; ANSWER SECTION: aol.com.2805IN MX 15 mailin-01.mx.aol.com. aol.com.2805IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507 That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;)
Re: Why choose 120 volts?
If the pdu contains a surge suppressor and was designed for 120v, plugging in to 220 will cause the MOV that protects against transient over-voltage to emit smoke. The breaker or fuse is a current limiting device. Joel Pete Templin peteli...@templin.org wrote: Dave Larter wrote: Seems like if the c14 was connected to a 240v PDU the 5-15 would deliver 240v to the equipment, arc/pop tripping the breaker on the PDU as soon as it is connected killing power to everything on that PDU. Or am I missing something? If you plug a PDU into a service that's higher voltage than expected, why would the PDU circuit breaker trip? That breaker is measuring current, AFAICT, though in the end it might be measuring power. Regardless, it isn't measuring voltage, because that isn't constant (it's AC, after all) and is likely to drop under a short circuit, not skyrocket like the current will. pt
Huawei cx300
Guys, Anybody any experience with VPLS on Huawei cx300? Jack
Packet loss statistics
Is anyone aware of useful resources for packet loss over large LANs and WANs? Google turned up a nice statistics page for Qwest's network but not much else that seems useful to me. Our testing teams are trying to simulate expected network conditions and rather than go overboard, having something close to real-world parameters would be nice. Thanks! Ric
Re: Packet loss statistics
The Internet2 network publishes 10-second data for all interfaces on both its backbone network and the individual racklans in each of its cities: Backbone: http://dc-snmp.grnoc.iu.edu/i2net/ Racklans: http://dc-snmp.grnoc.iu.edu/i2net-hp/ Default graphs don't show errors. You need to create a custom graph and click the appropriate checkbox. If you want to view a large number of interfaces with their errors on a single page, you can create a Custom View that includes errors for any number of selected interfaces. -Chris On May 28, 2009, at 12:03 PM, Ric Messier wrote: Is anyone aware of useful resources for packet loss over large LANs and WANs? Google turned up a nice statistics page for Qwest's network but not much else that seems useful to me. Our testing teams are trying to simulate expected network conditions and rather than go overboard, having something close to real-world parameters would be nice. Thanks! Ric Chris Robb, Internet2 Manager of Operations O: 812.855.8604 C: 812.345.3188 ESCC/Internet2 Joint Techs July 19-23, 2009 - Indianapolis, Indiana http://jointtechs.es.net/indiana2009/
Re: Why choose 120 volts?
On Tue, 2009-05-26 at 12:39 -0700, Seth Mattinen wrote: I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? We are using 120V in our colocation spaces. I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. The reason why we are using 120V is because we have pre-existing equipment (such as PDUs) that only support 120V operation. I believe our newer PDUs support 120/208/240, but do not have the time to investigate that, and we still have a couple of older APC units still in service. Our servers don't really care which voltage we provide, most of the PSUs can determine 120 vs 240 automatically, even. Also, at least at Equinix Chicago, 120V service was cheaper when we colocated there. I do not know if this is the same case at Steadfast in Chicago, and as far as I know, HE does not offer 208/240 service in their Fremont-2 facility. I could be misinformed on that, though. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149
Re: Packet loss statistics
On May 28, 2009, at 12:03 PM, Ric Messier wrote: Is anyone aware of useful resources for packet loss over large LANs and WANs? Google turned up a nice statistics page for Qwest's network but not much else that seems useful to me. Our testing teams are trying to simulate expected network conditions and rather than go overboard, having something close to real-world parameters would be nice. Depending on what you want, you could use something like smokeping or owamp to measure your network. (Both can be easily found via the goog). There are also commercial packages (eg: firehunter) that can be utilized as well to measure your network. - jared
RIPE NCC does a series of interviews about IPv6 deployment
As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, I am proud to announce the first in a series of interviews. Andy Davidson of NetSumo ISP Consultancy discusses the IPv6 deployment they have done for their customers and themselves: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Cheers, Alex Band RIPE NCC
Re: Why choose 120 volts?
I have some similar input. At my company, we use both 120 and 208 volt depending on what servers we are putting in the racks. We can fill up every single rack to full capacity 100% of the time by using energy efficient servers. The fact that it is 120 volt or 208 volt hardly matters on most machines except Xeon/Opeteron class systems. We use a lot of Core 2 duo, Atom and Xeon Low Voltage processors. This allows us higher density on the same power and makes 208 volt mostly irrelevant. On Thu, May 28, 2009 at 11:18 AM, William Pitcock neno...@systeminplace.net wrote: On Tue, 2009-05-26 at 12:39 -0700, Seth Mattinen wrote: I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? We are using 120V in our colocation spaces. I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. The reason why we are using 120V is because we have pre-existing equipment (such as PDUs) that only support 120V operation. I believe our newer PDUs support 120/208/240, but do not have the time to investigate that, and we still have a couple of older APC units still in service. Our servers don't really care which voltage we provide, most of the PSUs can determine 120 vs 240 automatically, even. Also, at least at Equinix Chicago, 120V service was cheaper when we colocated there. I do not know if this is the same case at Steadfast in Chicago, and as far as I know, HE does not offer 208/240 service in their Fremont-2 facility. I could be misinformed on that, though. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149
Re: Packet loss statistics
On Thu, 28 May 2009, Jared Mauch wrote: On May 28, 2009, at 12:03 PM, Ric Messier wrote: Is anyone aware of useful resources for packet loss over large LANs and WANs? Google turned up a nice statistics page for Qwest's network but not much else that seems useful to me. Our testing teams are trying to simulate expected network conditions and rather than go overboard, having something close to real-world parameters would be nice. Depending on what you want, you could use something like smokeping or owamp to measure your network. (Both can be easily found via the goog). Thanks, Jared. I'm not looking to quantify my network. I'm looking to introduce artificial errors into a test network to see the behavior against a product/system. I'd like to know if there is any data anywhere on what might be expected on an average network. I'm not sure there are such statistics, to be honest but thought I'd ask in the best place I knew to ask. Here is the Qwest link mentioned, by the way, in case anyone else is interested. http://stat.qwest.net/statqwest/perfRptIndex.jsp Ric
XO fiber cut (unverified) in St. Louis, MO
I've heard an unverified report that XO may have a fiber cut somewhere in St. Louis. Has anyone heard something similar? -- Major Hayden ma...@mhtx.net
DNS ed.gov translations
Greetings, Periodically, we loose the capability of translating .ed.gov names. Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that will not translate. If I use dig I get: porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov ; DiG 9.4.3-P1 +trace www.fafsa.ed.gov ;; global options: printcmd . 499251 IN NS L.ROOT-SERVERS.NET. . 499251 IN NS M.ROOT-SERVERS.NET. . 499251 IN NS H.ROOT-SERVERS.NET. . 499251 IN NS D.ROOT-SERVERS.NET. . 499251 IN NS A.ROOT-SERVERS.NET. . 499251 IN NS K.ROOT-SERVERS.NET. . 499251 IN NS B.ROOT-SERVERS.NET. . 499251 IN NS G.ROOT-SERVERS.NET. . 499251 IN NS E.ROOT-SERVERS.NET. . 499251 IN NS I.ROOT-SERVERS.NET. . 499251 IN NS J.ROOT-SERVERS.NET. . 499251 IN NS C.ROOT-SERVERS.NET. . 499251 IN NS F.ROOT-SERVERS.NET. ;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms gov.172800 IN NS E.GOV.ZONEEDIT.COM. gov.172800 IN NS G.GOV.ZONEEDIT.COM. gov.172800 IN NS A.GOV.ZONEEDIT.COM. gov.172800 IN NS B.GOV.ZONEEDIT.COM. gov.172800 IN NS C.GOV.ZONEEDIT.COM. gov.172800 IN NS D.GOV.ZONEEDIT.COM. gov.172800 IN NS F.GOV.ZONEEDIT.COM. ;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 82 ms ed.gov. 86400 IN NS eduptcdns02.ed.gov. ed.gov. 86400 IN NS eduftcdns01.ed.gov. ed.gov. 86400 IN NS eduftcdns02.ed.gov. ed.gov. 86400 IN NS eduptcdns01.ed.gov. ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in 84 ms dig: couldn't get address for 'eduftcdns01.ed.gov': not found porthos2:~ pcharbon2$ It always seems to fail after the third lookup sequence. After about an hour (or two or eight) it starts working again for some period of time. I am out of troubleshooting tools and don't know where to go from here. Any help would be greatly appreciated. PeteC Peter Charbonneau Sr. Network and Systems Administrator Williams College (413) 597-3408 (office) (413) 822-2922 (cell) OIT will NEVER ask for your password!
Re: Why choose 120 volts?
Admittedly no one I know is nuts enough to use body parts for liveness testing. Depends whose parts they're using Just to make things clear, I am NOT going to suggest you should do so, just telling you what I think I heared. I'm waiting for Randy to suggest his competitors do so brandon
Re: Packet loss statistics
On Thu, May 28, 2009 at 9:55 AM, Ric Messier kil...@washere.com wrote: Here is the Qwest link mentioned, by the way, in case anyone else is interested. http://stat.qwest.net/statqwest/perfRptIndex.jsp The equivalent ATT network performance portal page is http://www.att.com/ipnetwork and various pages linked to it. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: MX Record Theories
On May 28, 2009, at 5:04 AM, Bobby Mac wrote: If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. Well, it needs to resolve to an A RR somehow, but for each domain name, you get a different query. DNS by default starts with UDP which has a limit to the datagram size (64bit). The UDP minimum datagram size that must be supported by DNS implementations is 512 bytes. The maximum is 64K bytes. Obviously if you try to send a 64K byte packet, it's going to fragment and as we all know, fragments are bad. A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). If the response to a query won't fit in the UDP buffer (512 by default, although modern client implementations can advertise a larger buffer with EDNS0), the server will signal truncation in the response (with the TC bit), typically resulting in the client retransmitting the request via TCP. Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. IPv6 packets are a bit larger, but not that much. DNSSEC is where the fun starts. Regards, -drc
problems with cisco 7200 and PA-T3
Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856
Re: MX Record Theories
In message c3de0a330905280804t56ca87dapd94281399202...@mail.gmail.com, Bobby Mac writes: Not entirely on subject but I thought that allowing DNS queries to occur via TCP is mission critical for simple mail routing. We ran across this back in the day at @Home Network. Firewall rules were changed to not allow port 53 TCP. This severely affected sending mail to large distribution lists. Here is what we found and forgive me if I don't go into too much detail as it was almost 10 years a go. As I said, sites just don't do this as it causes serious problems. Sites that disable TCP/53 outbound just end up re-enabling it. Nameservers and stub resolvers automatically retry with TCP and the client applications just don't get answers returned when you start blocking TCP/53 outbound. It doesn't take long for said stupidity to be reversed. If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. DNS by default starts with UDP which has a limit to the datagram size (64bit). A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. The number of recipients has no impact on the size of the DNS responses. It will have a impact on the number of DNS queries made iff the receipents are in multiple mail domains. Mark -BobbyJim -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS ed.gov translations
In message c0fcea35-9d75-4841-8ff4-1e7a68c17...@williams.edu, Peter Charbonneau writes: Greetings, Periodically, we loose the capability of translating .ed.gov names. Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that will not translate. If I use dig I get: porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov ; DiG 9.4.3-P1 +trace www.fafsa.ed.gov ;; global options: printcmd . 499251 IN NS L.ROOT-SERVERS.NET. . 499251 IN NS M.ROOT-SERVERS.NET. . 499251 IN NS H.ROOT-SERVERS.NET. . 499251 IN NS D.ROOT-SERVERS.NET. . 499251 IN NS A.ROOT-SERVERS.NET. . 499251 IN NS K.ROOT-SERVERS.NET. . 499251 IN NS B.ROOT-SERVERS.NET. . 499251 IN NS G.ROOT-SERVERS.NET. . 499251 IN NS E.ROOT-SERVERS.NET. . 499251 IN NS I.ROOT-SERVERS.NET. . 499251 IN NS J.ROOT-SERVERS.NET. . 499251 IN NS C.ROOT-SERVERS.NET. . 499251 IN NS F.ROOT-SERVERS.NET. ;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms gov. 172800 IN NS E.GOV.ZONEEDIT.COM. gov. 172800 IN NS G.GOV.ZONEEDIT.COM. gov. 172800 IN NS A.GOV.ZONEEDIT.COM. gov. 172800 IN NS B.GOV.ZONEEDIT.COM. gov. 172800 IN NS C.GOV.ZONEEDIT.COM. gov. 172800 IN NS D.GOV.ZONEEDIT.COM. gov. 172800 IN NS F.GOV.ZONEEDIT.COM. ;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 82 ms ed.gov. 86400 IN NS eduptcdns02.ed.gov. ed.gov. 86400 IN NS eduftcdns01.ed.gov. ed.gov. 86400 IN NS eduftcdns02.ed.gov. ed.gov. 86400 IN NS eduptcdns01.ed.gov. ;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in 84 ms dig: couldn't get address for 'eduftcdns01.ed.gov': not found porthos2:~ pcharbon2$ It always seems to fail after the third lookup sequence. After about an hour (or two or eight) it starts working again for some period of time. I am out of troubleshooting tools and don't know where to go from here. Any help would be greatly appreciated. PeteC Peter Charbonneau Sr. Network and Systems Administrator Williams College (413) 597-3408 (office) (413) 822-2922 (cell) OIT will NEVER ask for your password! What nameserver and version are you running? What options do you have turned on in the nameserver? What firewall settings do you have? Do you allow fragments through? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS ed.gov translations
On May 28, 2009, at 8:37 PM, Mark Andrews wrote:
In message c0fcea35-9d75-4841-8ff4-1e7a68c17...@williams.edu,
Peter Charbonneau writes:
Greetings,
Periodically, we loose the capability of translating .ed.gov names.
Today, it seems that it is www.dl.ed.gov and www.fafsa.ed.gov that
will not translate.
If I use dig I get:
porthos2:~ pcharbon2$ dig +trace www.fafsa.ed.gov
; DiG 9.4.3-P1 +trace www.fafsa.ed.gov
;; global options: printcmd
. 499251 IN NS L.ROOT-SERVERS.NET.
. 499251 IN NS M.ROOT-SERVERS.NET.
. 499251 IN NS H.ROOT-SERVERS.NET.
. 499251 IN NS D.ROOT-SERVERS.NET.
. 499251 IN NS A.ROOT-SERVERS.NET.
. 499251 IN NS K.ROOT-SERVERS.NET.
. 499251 IN NS B.ROOT-SERVERS.NET.
. 499251 IN NS G.ROOT-SERVERS.NET.
. 499251 IN NS E.ROOT-SERVERS.NET.
. 499251 IN NS I.ROOT-SERVERS.NET.
. 499251 IN NS J.ROOT-SERVERS.NET.
. 499251 IN NS C.ROOT-SERVERS.NET.
. 499251 IN NS F.ROOT-SERVERS.NET.
;; Received 488 bytes from 137.165.4.21#53(137.165.4.21) in 2 ms
gov.172800 IN NS E.GOV.ZONEEDIT.COM.
gov.172800 IN NS G.GOV.ZONEEDIT.COM.
gov.172800 IN NS A.GOV.ZONEEDIT.COM.
gov.172800 IN NS B.GOV.ZONEEDIT.COM.
gov.172800 IN NS C.GOV.ZONEEDIT.COM.
gov.172800 IN NS D.GOV.ZONEEDIT.COM.
gov.172800 IN NS F.GOV.ZONEEDIT.COM.
;; Received 274 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in
82
ms
ed.gov. 86400 IN NS eduptcdns02.ed.gov.
ed.gov. 86400 IN NS eduftcdns01.ed.gov.
ed.gov. 86400 IN NS eduftcdns02.ed.gov.
ed.gov. 86400 IN NS eduptcdns01.ed.gov.
;; Received 202 bytes from 216.55.155.29#53(A.GOV.ZONEEDIT.COM) in
84 ms
dig: couldn't get address for 'eduftcdns01.ed.gov': not found
porthos2:~ pcharbon2$
It always seems to fail after the third lookup sequence.
After about an hour (or two or eight) it starts working again for
some
period of time.
I am out of troubleshooting tools and don't know where to go from
here. Any help would be greatly appreciated.
PeteC
Peter Charbonneau
Sr. Network and Systems Administrator
Williams College
(413) 597-3408 (office)
(413) 822-2922 (cell)
OIT will NEVER ask for your password!
What nameserver and version are you running?
What options do you have turned on in the nameserver?
What firewall settings do you have? Do you allow fragments
through?
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Bind 9.4.2
-- named.conf options -
options {
directory /var/named; // sets root dir, use full path to
escape
statistics-file /var/named/named.stats; // stats are your
friend
dump-file /var/named/named.dump;
zone-statistics yes;
allow-recursion { 127.0.0.1; 137.165.0.0/16; }; // allow
recursive lookups
allow-transfer { none; }; // allow transfers to these IP's
notify no; // dont notify the above IP's when a zone is
updated, since we are a slave server
pid-file /var/run/named/named.pid;
transfer-format many-answers; // Generates more efficient
zone transfers
listen-on { any; };
};
// Include logging config file
include /var/named/conf/logging.conf;
// Include to ACLs
include /var/named/conf/acls.conf;
// Include TSIG Keys
include /etc/bind/keys.conf;
Firewalls are Cisco ASAs that pass all traffic to/from the nameservers.
Fragments are allowed through.
What dig (above) shows is typical of the problem we see. We get to
that tier and one of the listed servers (in this case
eduftcdns01.ed.gov) fails to respond. If I try to ping it or
traceroute to it, I can't get to it. Shouldn't bind, then, try one of
the other three servers listed?
PeteC
Peter Charbonneau
Sr. Systems and Network Administrator
Williams College
(413) 597-3408 (D)
(413) 822-2922 (C)
RE: problems with cisco 7200 and PA-T3
Adam you could be tx the errors so your interface won't see them. On the other side of the circuit are they seeing errors on the rx. -carlos -Original Message- From: Adam Goodman [mailto:a...@wispring.com] Sent: Thursday, May 28, 2009 3:44 PM To: nanog@nanog.org Subject: problems with cisco 7200 and PA-T3 Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856
RE: problems with cisco 7200 and PA-T3
We have many 7200vxr's with DS3 interfaces. Though I am not sure this would be a interface problem. When you say that your provider sees errors on the circuit, where are they putting equipment? Is it an in-line test or an end to end test? Also, how is the DS3 being delivered? Be sure to check your coax and connectors. If you are only getting 5mbps on the line, I would ask your provider to come out and show you on a test set an end to end sweep from Point A to Point B. If you are getting data, and do not have AIS - I would assume somewhere something isn't up to spec physically. Feel free to ping me off list Adam. //warren Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile -Original Message- From: Adam Goodman [mailto:a...@wispring.com] Sent: Thursday, May 28, 2009 2:44 PM To: nanog@nanog.org Subject: problems with cisco 7200 and PA-T3 Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? Please hit me off list Thank you, Adam 801.971.1856
Issues through ATT core/backbone
We have a few circuits with ATT and a few VZ. Since friday we have seen serveral intermittent issues throught ATT to reach various customers and our various remote offices. If we swing the traffic through VZ interfaces using static routes we can reach those locations fine. We were doing traceroutes during the issue and we saw the traceroutes dying inside ATT network. I was wondering if any one else saw similar issues ? On friday we saw issue between ATT and GBLX peering point. We saw similar issue on tuesday. And another one today. We sent to ATT various traceroutes and opened a few tickets but didnt really get any kind of confirmation. The problem seems to remedy itself on its own after 10-30 minutes. Please chime in if any one else saw similar issues transiting through ATT or global crossing.
Re: problems with cisco 7200 and PA-T3
Adam Goodman wrote: Just installed a cisco 7204vxr with a DS3 interface. we are not getting more than 5Mbits. show interface is not reporting any errors. the provider tech put a piece test equipment on the circuit and sees errors. Do you have access to both ends of the circuit? No errors on either end? In which direction does the provider tech show errors and where in the circuit is the test set being placed? Does the test set show errors running to a hard (co-ax) loop? if so you have a problem with the span. Have you verified that there is exactly one clocking source on the circuit? Does anyone else use a cisco 7200 with a DS3 interface that we might be able to speak with? We have several. In some cases a 10dB attenuator is needed on the receive side if the carrier is too hot but this manifests as errors. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
RE: navog?
One more: isp-voiceoverip (http://isp-lists.isp-planet.com/isp-voiceoverip/resources/). Pretty quiet, though. Frank -Original Message- From: J. Oquendo [mailto:s...@infiltrated.net] Sent: Thursday, May 28, 2009 9:34 AM To: nanog@nanog.org Subject: Re: navog? Jared Mauch wrote: On May 28, 2009, at 10:16 AM, J. Oquendo wrote: david hiers wrote: Hi, Is anyone aware of a voip-focused group similar to nanog? Us voip pukes have to deal with the issues of allocation, routing, and management of phone numbers as well as networks, and I have not found a voice operators' group similar to this network operators' group. Thanks, David On the other hand, I don't know that I'd want to see a multitude of messages from someone saying My trixbox dialplan doesn't work! or, (broken english purposely inserted) Why my Cisco Call Manager is tell me to partition! Actually, there is a quite active cisco-voip list over on puck that discusses exactly the CM issues you refer to. (I diverted everyone to that list to keep it off c-nsp and it seems to have grown since). - Jared http://puck.nether.net/mailman/listinfo/cisco-voip (removed cc's to avoid sending dupes) Agreed, I browse through some of the stuff there and indeed it works for cisco telephony matters. Cisco staff has provided some really good guidance on matters there, as have Digium staffers for Asterisk's mailing list. But I can't really envision an all inclusive VoIP list with regards to the carrier end, equipment end, programming end, etc. Heaven knows I would have like to discuss Nortel and Avaya matters countless times but then those conversations would have actually ended up shifting towards SIP in which to a degree, they wouldn't have even had anything to do with the vendors at all. So I view it as a tough call. Anyhow, perhaps links should be included: http://voipsa.org/VOIPSEC/ (VoIPSA - VoIP Security related) http://puck.nether.net/mailman/listinfo/cisco-voip (Cisco VoIP related) http://lists.digium.com/mailman/listinfo/asterisk-users (Asterisk Users) http://groups.yahoo.com/group/sip-config (SIP Config (mainly spam now)) http://sipforum.org/pipermail/discussion/index.html (SIP forum) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x5CCD6B5E
