- Test - lists.nanog.org

interger to I P address
by chartley＠oar.net 27 Aug '08

27 Aug '08

Sorry to be continuing this thread, but I find a certain kind of elegance in bash which isn't actually there, but helps me sleep at night. bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\. '{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\. '{print $4}'`; echo $[($oct1<<24)+($oct2<<16 )+($oct3<<8)+$oct4 ];} bash# inttoip(){ echo $[$1>>24].$[($1>>16)&255].$[($1>>8)&255].$[$1&255]; } bash# inttoip 1089055123 64.233.169.147 bash# iptoint 64.233.169.147 1089055123 Chris

5 4

Re: interger to I P address
by bfeeny＠mac.com 27 Aug '08

27 Aug '08

The NANOG way: www.google.com ------Original Message------ From: Boyd, Benjamin R To: Andree Toonk To: nanog(a)nanog.org Sent: Aug 27, 2008 12:38 PM Subject: RE: interger to I P address >>> The harder way: >>> >>> Decimal: 1089055123 >>> Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of >each octet): >>> 64-233-169-147 IP Address: 64.233.169.147 >> >> The Python way >> >> >>> import socket, struct >> >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) >> '64.233.169.147' > >The Perl way: > >sub ntoa >{ > my $one = shift; > my $four = $one & 0xff; > $one >>= 8; > my $three = $one & 0xff; > $one >>= 8; > my $two = $one & 0xff; > $one >>= 8; > return "$one.$two.$three.$four"; >} > >#or in one line, like ipcalc does: >sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > >print ntoa(1089055123) . "\n"; >print ntoa_in_one_line(1089055123) . "\n"; > > The PHP way: function convertIntegerToIpv4($integer) { $max_value = pow(2,32); //4,294,967,296 $bug_fix = 0; settype($integer, float); if($integer > 2147483647) $bug_fix = 16777216; if(is_numeric($integer)) { if ($integer >= $max_value || $integer < 0) { return ('Not a valid IPv4 integer'); } $ip = (sprintf("%u.%u.%u.%u", $integer / 16777216, (($integer % 16777216) + $bug_fix) / 65536, (($integer % 65536) + $bug_fix / 256) / 256, ($integer % 256) + $bug_fix / 256 / 256 ) ); return($ip); } else { return(''); } } *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. Sent from my Verizon Wireless BlackBerry

1 0

BGP, ebgp-multihop and multiple peers
by Steve Bertrand 27 Aug '08

27 Aug '08

Hi everyone, This question comes after likely overlooking an IETF document or BCP that describes what I'm after. Given that I am looking for advice from someone who is more experienced operationally in this regard than me, and that this technically is an implementation-neutral question, I wanted to ask here. Taking one router I have as an example, I have four IPv6 BGP peers (two are for true routing, the other two for route server projects), and five IPv4 BGP peers. Two of the v4 peers are Cymru for BOGONS, the other three are purely outbound to route server projects. All five v4 peers are ebgp-multihop. I'm looking for advice on the configuration of the peers with ebgp-multihop (IPv4). I have a reserved block carved out of my allocation specifically for /32s on loopbacks, and when I light up a new peer, I configure a new looopback interface for that peer, and subsequently give it the next available IP from the reserved /32 block. There are numerous drawbacks to doing it this way... waste of IPv4 addresses, additional keystrokes on the router for interface config, documentation, expanded margin for error et-al. There are a few benefits to doing it this way (IMHO), but I see obvious benefits of using a single loopback interface and single IP for ALL of these multihop peers. Before I state good/bad, or get any wrong idea in my head, I'd like to ask the real experts here which way they would/do this type of thing, and why. - single loopback/single IP for all peers, or; - each peer with its own loopback/IP? Thanks, Steve

5 7

Re: Level 3 TPA routing today?
by Paul Wall 27 Aug '08

27 Aug '08

Confirmed outage on their side. Should be resolved now. Drive Slow, Paul Wall On Wed, Aug 27, 2008 at 1:37 AM, Scott Berkman <scott.berkman(a)reignmaker.net> wrote: > We've also been seeing some "weird" (hard to track down) issues all day > with Level 3 in both Tampa and Atlanta, especially from our NMS systems > monitoring systems all over the place. > > My contact at Level 3 didn't know of anything going on and couldn't really > find anything. Anyone else have a Level 3 response? > > -Scott > > -----Original Message----- > From: Peter Beckman [mailto:beckman@angryox.com] > Sent: Tuesday, August 26, 2008 9:40 PM > To: nanog(a)merit.edu > Subject: Re: Level 3 TPA routing today? > > On Tue, 26 Aug 2008, david raistrick wrote: > >> On Tue, 26 Aug 2008, David Hubbard wrote: >> >>> Anyone seeing issues with Level 3 between anywhere >>> and Tampa, particularly Atlanta and Dallas? We've >> >> Internap just reported problems with L3 out of Miami: >> >> "we are seeing latency, minor packet loss and path problems to a >> number of destinations and other PNAPs via our Level3 (AS3356) upstream >> connection in the MIA003 PNAP. " > > I've been seeing 30-70% packet loss between Cox Business and Level3 from > DC to NY since 8:17pm EDT. Maybe via Internap? > > Loss% Snt Last Avg Best Wrst > StDev > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 100 2.4 5.1 2.2 51.9 > 8.3 > 4. xe-9-2-0.edge1.Washington1.L 67.0% 100 2.5 6.8 2.4 41.6 > 8.6 > 5. vlan99.csw4.Washington1.Leve 69.0% 100 2.7 8.3 2.6 23.7 > 5.0 > 6. ae-93-93.ebr3.Washington1.Le 68.0% 100 3.0 9.9 2.7 30.9 > 6.3 > 7. ae-3.ebr3.NewYork1.Level3.ne 70.0% 100 10.5 15.8 8.1 44.2 > 8.8 > 8. ae-83-83.csw3.NewYork1.Level 71.0% 100 18.9 14.2 8.1 42.0 > 7.1 > 9. ae-31-89.car1.NewYork1.Level 66.0% 100 8.6 25.7 8.5 165.4 > 41.7 > > Beckman > -------------------------------------------------------------------------- > - > Peter Beckman Internet > Guy > beckman(a)angryox.com > http://www.angryox.com/ > -------------------------------------------------------------------------- > - > > >

1 0

OT but funny: shades of gallery.colofinder.net
by Paul Wall 26 Aug '08

26 Aug '08

Not to pick on the Democrats unduly - they just went first in terms of giving us crummy cabling as a metaphor for crummy government; inshallah the Republicans will give us something as good or better when they have their turn next week... http://www.wired.com/techbiz/media/multimedia/2008/08/gallery_dnc_tech?slid… Is anyone still running a cabling horror show photo rogue's gallery? Drive Slow, Paul Wall

7 7

speaking of slightly OT but perhaps still operational content
by Dorn Hetzel 26 Aug '08

26 Aug '08

I noticed where the democrats plan to ask a stadium full of people to all use their cellphones at the same time (on Thursday, I believe) Any thoughts on how useable cell service will or wont be in the vicinity of this event? :) -Dorn

5 5

Where to put our router
by Jake Mertel 26 Aug '08

26 Aug '08

Good afternoon (or whatever it is for you ;), We have just finished moving a large amount of equipment to a new facility outside of downtown Chicago. At present we have an uplink via a point-to-point to Equinox downtown. We are preparing to add another provider, and are debating where we should put our router. The two options would be in Equinox downtown (co-located with our existing provider) or at the new facility. Were we to do the former we would turn our existing point-to-point into our connection from our edge router to our distribution switch and add a second point-to-point for redundancy from the distro switch back to the router. Were we to do the latter we would get a second point-to-point direct from our new provider to their network and connect it to our router where it is now. The major advantage I can think of to having it in Equinox is the availability of cross connects to just about anyone. There are a few providers in the new facility, but not many. The major disadvantage is that if we suddenly need a large amount of transport (i.e. a new large client, a definitive short-term possibility) we would either need to get a new or additional point-to-point from downtown to the facility or would need to get another router to utilize at the new facility (were we to meet up with one of the in-building providers instead of getting the point-to-point transport). Any thoughts related to the advantages or disadvantages of doing one or the other would be greatly appreciated. Thanks in advance. Kind regards, Jake Mertel Nobis Technology Group, L.L.C.

1 0

Domain Security risk?
by Jim McBurnett 26 Aug '08

26 Aug '08

Hey folks, I have a customer that owns a domain and has owned it for years. Out of the blue they got an email from Asia Internet Network Information Center. They claim to be an approved Domain name dispute resolution committee member. When I researched it: http://www.adndrc.org/adndrc/index.html They do not appear to be "approved". Has anyone had dealings with them? Currently I am pushing this to ICANN and Network Solutions (domain registrar). Comments? Ideas? Thanks, Jim McBurnett Senior Network Engineer CCNP,CCVP, CCDA Thomas Glover Associates, Inc. 864-473-1200 x 106 office 864-641-5863 Cell

3 2

It's Ars Tech's turn to bang the IPv4 exhaustion drum
by Jay R. Ashworth 26 Aug '08

26 Aug '08

http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addr… Well, on reading it, it's more an "IPv6: It's great -- ask for it by name!" piece. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

14 16

Out of Date Bogon Prefix
by Nick Downey 26 Aug '08

26 Aug '08

This is an heads-up from the Mediacom Network Operations Center about an issue we are seeing. We were recently given an IP scope from ARIN (American Registry for Internet Numbers) that still exists on older Bogon lists many web providers are currently using. A Bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a Bogon range. These are commonly found as the source addresses of DDoS attacks. The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all websites using a Bogon prefix up until February of 2008, when it was released by IANA (Internet Assigned Numbers Authority) for public use and an updated Bogon prefix was provided. Mediacom customers that are within this IP range are not able to reach a website hosted by many organizations. Mediacom is individually requesting that these providers update their Bogon prefix to the most current version to resolve this issue immediately. We are requesting assistance from this community to make this issue known and to advise administrators to update to the most current Bogon list. We have provided some reference material that many may find helpful in resolving this issue. Bogons are defined as Martians (private and reserved addresses defined by <http://www.ietf.org/rfc/rfc1918.txt> RFC 1918 < <http://www.faqs.org/rfcs/rfc1918.html> http://www.faqs.org/rfcs/rfc1918.html> and <http://www.ietf.org/rfc/rfc3330.txt> RFC 3330 < <http://www.faqs.org/rfcs/rfc3330.html> http://www.faqs.org/rfcs/rfc3330.html>) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority < <http://www.iana.org/> http://www.iana.org/>. IANA maintains a convenient IPv4 summary page < <http://www.iana.org/assignments/ipv4-address-space> http://www.iana.org/assignments/ipv4-address-space> listing allocated and reserved netblocks. Please help to spread the word. Nick Downey Director Network Operations Center Mediacom Communications Main (800)308-6715 Secondary (515)267-1167 ndowney(a)mediacomcc.com ============================================================================ ================================================================ LEGAL DISCLAIMER ============================================================================ ================================================================ This E-mail and any attachments are strictly confidential and intended solely for the addressee. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender or Mediacom Communications Corporation. If you are not the intended addressee please notify the sender by return E-mail and delete this E-mail and its attachments. ============================================================================ ================================================================

46 122