Re: shared address space... a reality!
On 15 Mar 2012, at 21:03, valdis.kletni...@vt.edu wrote: On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said: What, senior network people testing out new test/transitional space at home before they test it at work is bad? Either that, or Randy was being snarky about how long the promise to *only* use the address space for numbering CGN interfaces and not as additional RFC1918 space was going to last in reality So where is that new /10 leaking to already? ;). Tim
Re: Anyone have experience with Adconion Direct?
If a company has a ROKSO record, you don't want to host them. And spamhaus IS responsive. Yes they don't take spam reports from people - they got their own traps. They ARE responsive to requests for removal where the request checks out and meets their criteria. On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymer m...@viviotech.net wrote: Also along the lines of spammers and or similar activities is there a good resource for looking up people/companies that might be not so legit? I know of the ROKSO that spamhaus has but from what I have seen it is hard to even report spammer to them and wasn't sure how active that was getting updated these days. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Shim6, was: Re: filtering /48 is going to be necessary
2012/3/16 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: William Herrin wrote: As LS requires less intelligence than DV, it converges faster. I do believe that's the first time I've heard anybody suggest that a link state routing protocol requires less intelligence than a distance vector protocol. I mean intelligence as intermediate systems. DV is a distributed computation by intelligent intermediate systems, whereas, with LS, intermediate systems just flood and computation is by each end. That's basically wrong. Both systems perform computation on each router. Link State performs much more complex computation to arrive at its export to the forwarding information base. In fact, Distance Vector's calculation is downright trivial in comparison. The difference is that Link State shares the original knowledge, which it can do before recomputing its own tables. Distance Vector recomputes its own state first and then shares each router's state with the neighbors rather than sharing the original knowledge. The result is that the knowledge propagates faster with Link State and each router recomputes only once for each change. In some cases, distance vector will have to recompute several times before the system settles into a new stable state, delaying the process even further. Here is an exercise for you insisting on DNS, an intermediate system. What if DNS servers, including root ones, are mobile? DNS' basic bootstrapping issues don't change, nor do the solutions. The resovlers find the roots via a set of static well-known layer 3 address You failed to deny MH know layer 3 address of its private HA. Here's a tip for effective written communication: the first time in any document that you use an abbreviation that isn't well known, spell it out. It's waste of resource for MH have well known IP address of root servers and domain names of its private DNS server and security keys for dynamic update only to avoid to know IP address of its private HA. There's no reason for the Mobile Host to know the IP addresses of the root servers. Like any other host, including MH in your plan, it already knows its domain name and the IP addresses of its private DNS servers. That leaves only the security key. So, by your own accounting I swap knowledge of a topology-independent element (the security key) for a topology-dependent element (an IP address) which may change any time you adjust your home agent's required-to-be-landed network with all of today's vagaries around the renumbering problem. For that matter, how do you solve the problem with your home agent approach? Is it even capable of having multiple home agents active for each node? How do you keep them in sync? I actually designed and implemented such a system. Multiple home agents each may have multiple addresses. If some address of HA does not work, MH tries other addresses of HA. If some HA can not communicate with MH, CH may try to use other HA. There is nothing mobility specific. Mobile protocols are modified just as other protocols are modified for multiple addresses. In practice, however, handling multiple addresses is not very useful because selection of the best working address is time consuming unless hosts have default free routing tables. In your home agent architecture, it doesn't matter if they can have multiple addresses. It matters if they can have the same address. Otherwise you're pushing off the generalized continuity of operations problem. One which my DNS add/drop approach handles seamlessly and at a granularity of the individual services on the mobile host. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Flexible BGP liist?
On Thu, 15 Mar 2012 22:41:18 -0400, Joe Maimon jmai...@ttec.com wrote: So we have a wiki list of 1U rack hosting. How about a list of SP's willing to configure BGP over whatever you got, including tunnels? And willing to allocate you space for same? Put me down there. Joe I can't speak for IPv4, but I know Hurricane Electric is doing BGP with me for my IPv6 block over a tunnel, free, through their tunnelbroker.net site. -Scott
Re: Flexible BGP liist?
Le 16/03/12 03:41, Joe Maimon a écrit : How about a list of SP's willing to configure BGP over whatever you got, including tunnels? Depends on what you're looking for : transit over tunnels is prety rare because it's generally a bad idea (MTU issues, BW cost over transits). If you just want to get a BGP feed for studies and statistics, with no forwarding involved, I guess I'd be willing to participate (AS197422). But an eBGP multihop session is enough, no need for a tunnel there. And willing to allocate you space for same? Isn't any RIR memeber list sufficient ? -- Jérôme Nicolle 06 19 31 27 14
Iowa outage(s)?
Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is statewide. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
RE: Iowa outage(s)?
FYI Darin Herteen CCNA Lead Network Technician Packet Networking Group Iowa Network Services Inc http://www.iowanetworkservices.com -Original Message- From: Mike Andrews [mailto:mi...@mikea.ath.cx] Sent: Friday, March 16, 2012 11:04 AM To: nanog@nanog.org Subject: Iowa outage(s)? Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is statewide. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: Iowa outage(s)?
On Fri, Mar 16, 2012 at 04:08:37PM +, Darin Herteen wrote: FYI Darin Herteen CCNA Lead Network Technician Packet Networking Group Iowa Network Services Inc http://www.iowanetworkservices.com -Original Message- From: Mike Andrews [mailto:mi...@mikea.ath.cx] Sent: Friday, March 16, 2012 11:04 AM To: nanog@nanog.org Subject: Iowa outage(s)? Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is statewide. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Appears to have been resolved: ;; QUESTION SECTION: ;dns1.rdi1.com. IN A ;; ANSWER SECTION: dns1.rdi1.com. 3600IN A 67.55.143.251 ;; AUTHORITY SECTION: rdi1.com. 164094 IN NS dns1.rdi1.com. rdi1.com. 164094 IN NS dns2.rdi1.com. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: [Full-disclosure] is my ISP lying or stupid?
You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest jerr...@mc.net wrote: They had a DoS of mail, www and shell. They state a switch went out. who runs mail, www and shell on the same switch? (This might be a trick question, think it thru...) bma -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
Re: Anyone have experience with Adconion Direct?
Hi, I guess I should clarify a bit more on my comments about ROKSO at Spamhaus. Spamhaus says here http://www.spamhaus.org/faq/section/ROKSO%20FAQ#159 that people that have been thrown off 3 ISP due to spamming or providing spam services get on the ROKSO. So I tried to contact them to see what the process was for reporting that. If someone here knows how to do that and would like to share that would be great. I do agree that to get delisted in the RBL etc they are responsive. Also per my main point I wanted to thank those of you that got back with me about Adconion Direct. Sincerely, Mark On 3/16/2012 2:51 AM, Suresh Ramasubramanian wrote: If a company has a ROKSO record, you don't want to host them. And spamhaus IS responsive. Yes they don't take spam reports from people - they got their own traps. They ARE responsive to requests for removal where the request checks out and meets their criteria. On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymer m...@viviotech.net mailto:m...@viviotech.net wrote: Also along the lines of spammers and or similar activities is there a good resource for looking up people/companies that might be not so legit? I know of the ROKSO that spamhaus has but from what I have seen it is hard to even report spammer to them and wasn't sure how active that was getting updated these days. -- Suresh Ramasubramanian (ops.li...@gmail.com mailto:ops.li...@gmail.com)
RE: [Full-disclosure] is my ISP lying or stupid?
I would have guess WOW cable. They lost their dns servers so many times, their recording on the help line was if you know the number address of the site you're going to, you can type that into your web browser -becki -Original Message- From: Chris [mailto:cal...@gmail.com] Sent: Friday, March 16, 2012 1:29 PM To: NANOG list Subject: Re: [Full-disclosure] is my ISP lying or stupid? You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest jerr...@mc.net wrote: They had a DoS of mail, www and shell. They state a switch went out. who runs mail, www and shell on the same switch? (This might be a trick question, think it thru...) bma -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
nfsen and protocol analysing plugin
Hi everybody, Does any body know any plugin for nfsen which can analyse protocols and give out report for us? ( using netflow ) By default nfsen only shows TCP, UDP and ICMP traffic not detail. For example I want to show me how much YMessenger traffic I have, or how much IMAP traffic I have. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: shared address space... a reality!
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. -- Octavio.
Re: nfsen and protocol analysing plugin
On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: Hi everybody, Does any body know any plugin for nfsen which can analyse protocols and give out report for us? ( using netflow ) By default nfsen only shows TCP, UDP and ICMP traffic not detail. For example I want to show me how much YMessenger traffic I have, or how much IMAP traffic I have. I think you want the PortTracker plugin. Goog for nfsen plugins and you'll find it. jms
Re: nfsen and protocol analysing plugin
Its a port tracker and traffic analyser, the plugin I want can gather valuable data from netflow. For example GTalk is on port 80 and this plugin can not detect it ;) Thanks On Fri, Mar 16, 2012 at 9:36 PM, Justin M. Streiner strei...@cluebyfour.org wrote: On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: Hi everybody, Does any body know any plugin for nfsen which can analyse protocols and give out report for us? ( using netflow ) By default nfsen only shows TCP, UDP and ICMP traffic not detail. For example I want to show me how much YMessenger traffic I have, or how much IMAP traffic I have. I think you want the PortTracker plugin. Goog for nfsen plugins and you'll find it. jms -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Spamhaus - Re: Anyone have experience with Adconion Direct?
They do read nanog I believe. So just changed the subject to tag it spamhaus On Fri, Mar 16, 2012 at 11:14 PM, Mark Keymer m...@viviotech.net wrote: Spamhaus says here http://www.spamhaus.org/faq/section/ROKSO%20FAQ#159that people that have been thrown off 3 ISP due to spamming or providing spam services get on the ROKSO. So I tried to contact them to see what the process was for reporting that. If someone here knows how to do that and would like to share that would be great. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: nfsen and protocol analysing plugin
On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: Its a port tracker and traffic analyser, the plugin I want can gather valuable data from netflow. For example GTalk is on port 80 and this plugin can not detect it ;) You're not going to get that kind of detail from Netflow. It doesn't have the visibility into application layer to tell you GTalk from straight HTTP, from any other traffic that might be riding on destination socket tcp/80. You need something with visibility and intelligence higher up in the stack (sniffer, packet inspection engine, etc). jms
Re: shared address space... a reality!
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? ha! Sure, this lets CGN to be more organized for operators, but those that ghuston has a great presentation about CGN deployments, and how they essentially become permanent (or could, according to his chickenbone-readings)... It's an interesting thought experiment/discussion, and one I'm curious to see play out. already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. are you really asking: Why on why did we go through all this hard work for something with basically no easy to quantify return? hell, this may get more use than SCTP does, and sctp took a LOT longer to do... -chris
Re: Anyone have experience with Adconion Direct?
On 03/16/2012 05:51 AM, Suresh Ramasubramanian wrote: If a company has a ROKSO record, you don't want to host them. And spamhaus IS responsive. Yes they don't take spam reports from people - they got their own traps. They ARE responsive to requests for removal where the request checks out and meets their criteria. On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymerm...@viviotech.net wrote: Also along the lines of spammers and or similar activities is there a good resource for looking up people/companies that might be not so legit? I know of the ROKSO that spamhaus has but from what I have seen it is hard to even report spammer to them and wasn't sure how active that was getting updated these days. I'll be honest and maybe I'm blowing off some steam but I didn't find them responsive the last few times I tried to contact them. I wasn't even trying to get my IPs off one their lists. While working for a previous employer I found out we had a customer that was just a d/b/a for a known ROKSO offender. I tried to give as much info as I could so Spamhaus could get their name out there and poison their reputation better than we could. All I ever got was maybe a reply once and then nothing. After the second time of no action I figured they didn't care. And the ROKSO info is still out of date. /rant
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 17 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 401129 Prefixes after maximum aggregation: 170803 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 194695 Total ASes present in the Internet Routing Table: 40373 Prefixes per ASN: 9.94 Origin-only ASes present in the Internet Routing Table: 32891 Origin ASes announcing only one prefix: 15486 Transit ASes present in the Internet Routing Table:5406 Transit-only ASes present in the Internet Routing Table:141 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 407 Unregistered ASNs in the Routing Table: 187 Number of 32-bit ASNs allocated by the RIRs: 2322 Number of 32-bit ASNs visible in the Routing Table:2076 Prefixes from 32-bit ASNs in the Routing Table:5015 Special use prefixes present in the Routing Table:2 Prefixes being announced from unallocated address space:687 Number of addresses announced to Internet: 2526912912 Equivalent to 150 /8s, 157 /16s and 161 /24s Percentage of available address space announced: 68.2 Percentage of allocated address space announced: 68.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 170384 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:98366 Total APNIC prefixes after maximum aggregation: 31927 APNIC Deaggregation factor:3.08 Prefixes being announced from the APNIC address blocks: 94757 Unique aggregates announced from the APNIC address blocks:39280 APNIC Region origin ASes present in the Internet Routing Table:4667 APNIC Prefixes per ASN: 20.30 APNIC Region origin ASes announcing only one prefix: 1233 APNIC Region transit ASes present in the Internet Routing Table:728 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table:165 Number of APNIC addresses announced to Internet: 640873312 Equivalent to 38 /8s, 50 /16s and 243 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:148801 Total ARIN prefixes after maximum aggregation:75607 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120341 Unique aggregates announced from the ARIN address blocks: 49824 ARIN Region origin ASes present in the Internet Routing Table:14938 ARIN Prefixes per ASN: 8.06 ARIN Region origin ASes announcing only one prefix:
dell switch config export
Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working... Thanks, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km
Re: dell switch config export
Jeroen van Aart(jer...@mompl.net)@Fri, Mar 16, 2012 at 12:04:04PM -0700: Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working... I'm using RANCID against a few 54xx PowerConnect switches, and it's working well enough. I'm pretty sure my dlogin and drancid came from http://web.rickyninja.net:81/rancid/drancid and http://web.rickyninja.net:81/rancid/dlogin . -- Bill Weiss
RE: shared address space... a reality!
From: Octavio Alvarez Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. -- Octavio. This is yet one more moving parts in the growing assemblage of moving parts that is required to make v4 work going forward. At some point (soon) we will reach a point of diminishing return and people are simply going to realize that it is easier to deploy v6 native than it is to attempt to keep v4 limping along. A new player is probably going to buy new gear. New gear isn't going to have the problems with v6 that older networks might have who could still be using ancient gear and can't afford to forklift their stuff out. A new player entering the market these days looking to use this for a native v4 deployment going forward any significant period of time ... is probably not making the wisest choice. And with every additional moving part there is something else that impacts performance, something else to break, something else to become CPU or memory bound ... performance over v4 will become increasingly poor, increasingly unreliable, and people are just going to realize that any pain of v6 migration is a lot less than keeping the bailing wire, super glue, and rubber bands around v4. This will be true of their own networks and the networks they are communicating with. V4 performance in general from here on out is simply going to go south. Umpteen NATs, routing table bloat as the nets shatter into smaller and smaller blocks, at some point v4 isn't worth it. Maybe we should just propose more and more and more Band-Aids. Many choose not to migrate to v6 out of simple laziness (if it ain't broken, don't fix it). At some point it will take so much more work to keep v4 going that the path of least phone calls in the middle of the night will be IPv6.
Re: shared address space... a reality!
On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? We forgot to ask if all the stakeholders wanted it solved. Most self-styled enterprise operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Programmers with network engineering skills
Steve Bertrand wrote: imo, this discussion of outbound SMTP has been sounding akin to me saying I should let my upstream ensure that all of my BGP announcements are good, instead of filtering my own outbound. know whether the address is to RFC or not. Less bugs and changes, I feel it is better to give the remote host known-good data then have to have them tell me it is bad. I don't think it's comparable. Because you would not use a remote MTA to validate your email address. You would use the MTA that listens on localhost on the server your code is running. It's really trivial to install an MTA that only listens on localhost and submits email to a smarthost. I mean, if you have code on a webserver that gets form data and sends out emails you best run an MTA locally to which you submit the email and be done with it. The local MTA will take care of queuing and all that for you and submits your email to a smarthost, und so weiter. In Perl for example, there is Email::Valid. One line of code and you Of course use something like that if it's available to you. Regards, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km
Re: shared address space... a reality!
In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6. If deploying IPv6 on your own network qualified as a complete solution to the problem, I suspect we'd actually be much further along in the process. Unfortunately, deploying IPv6 locally does not change the fact that you use the internet to talk to things not under your control and until they deploy IPv6, you cannot depend entirely on IPv6 to do that. I don't think any sane provider will use this as yet another way to avoid deploying IPv4. OTOH, the number of not sane providers is somewhat scary, but, hopefully not of sufficient critical mass as to be meaningful in the long term. Owen
Re: dell switch config export
Bill Weiss wrote: I'm using RANCID against a few 54xx PowerConnect switches, and it's working well enough. I'm pretty sure my dlogin and drancid came from http://web.rickyninja.net:81/rancid/drancid and http://web.rickyninja.net:81/rancid/dlogin . A number of people suggested that, thanks. I will look into that. Thanks, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km
Re: shared address space... a reality!
NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. Christian de Larrinaga On 16 Mar 2012, at 19:35, William Herrin b...@herrin.us wrote: On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? We forgot to ask if all the stakeholders wanted it solved. Most self-styled enterprise operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [Full-disclosure] is my ISP lying or stupid?
My team at Comcast is responsible for our mail platform and I'm not aware that we had an outage, Chris. If you have information to the contrary, please share it and I'll track it down. - Jason On 3/16/12 1:28 PM, Chris cal...@gmail.commailto:cal...@gmail.com wrote: You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest jerr...@mc.netmailto:jerr...@mc.net wrote: They had a DoS of mail, www and shell. They state a switch went out. who runs mail, www and shell on the same switch? (This might be a trick question, think it thru...) bma -- --C The dumber people think you are, the more surprised they're going to be when you kill them. - Sir William Clayton
Re: shared address space... a reality!
It may be easy to sell, but it's also fictitious. NAT is antithetical to security, not beneficial to it. Owen On Mar 16, 2012, at 1:21 PM, cdel.firsthand.net wrote: NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. Christian de Larrinaga On 16 Mar 2012, at 19:35, William Herrin b...@herrin.us wrote: On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? We forgot to ask if all the stakeholders wanted it solved. Most self-styled enterprise operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: shared address space... a reality!
On Fri, 16 Mar 2012 14:17:38 PDT, Owen DeLong said: It may be easy to sell, but it's also fictitious. NAT is antithetical to security, not beneficial to it. Anybody want to hazard a guess what % of Vint Cerf's famous 140M compromised boxes were behind a NAT and still got pwned by a drive-by fruiting? pgpODKcjPHbIL.pgp Description: PGP signature
BGP Update Report
BGP Update Report Interval: 08-Mar-12 -to- 15-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS24863 115152 4.6% 101.3 -- LINKdotNET-AS 2 - AS840262241 2.5% 29.9 -- CORBINA-AS OJSC Vimpelcom 3 - AS702935548 1.4% 12.6 -- WINDSTREAM - Windstream Communications Inc 4 - AS580031822 1.3% 106.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS982931131 1.2% 31.3 -- BSNL-NIB National Internet Backbone 6 - AS55515 28472 1.1%1186.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 7 - AS12479 28087 1.1% 52.4 -- UNI2-AS France Telecom Espana SA 8 - AS28683 27278 1.1% 462.3 -- BENINTELECOM 9 - AS32528 22751 0.9%2275.1 -- ABBOTT Abbot Labs 10 - AS24560 19840 0.8% 19.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - AS845216225 0.7% 12.8 -- TE-AS TE-AS 12 - AS211815478 0.6% 10.8 -- RELCOM-AS OOO NPO Relcom 13 - AS958314368 0.6% 11.8 -- SIFY-AS-IN Sify Limited 14 - AS755214026 0.6% 12.3 -- VIETEL-AS-AP Vietel Corporation 15 - AS606612624 0.5%6312.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 16 - AS41843 12134 0.5% 153.6 -- ERTH-OMSK-AS CJSC ER-Telecom Holding 17 - AS257812110 0.5% 25.2 -- DEMOS-AS Demos, Moscow, Russia 18 - AS684911858 0.5% 179.7 -- UKRTELNET JSC UKRTELECOM, 19 - AS13277 11262 0.5%5631.0 -- HP-MS HP-MS Autonomous System 20 - AS26615 10977 0.4% 12.2 -- Tim Celular S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS606612624 0.5%6312.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 2 - AS13277 11262 0.5%5631.0 -- HP-MS HP-MS Autonomous System 3 - AS8657 2514 0.1%2514.0 -- CPRM CPRM Autonomous System 4 - AS32528 22751 0.9%2275.1 -- ABBOTT Abbot Labs 5 - AS43643 0.1% 60.0 -- Maria Irma Salazar 6 - AS55515 28472 1.1%1186.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 7 - AS299333326 0.1%1108.7 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 8 - AS133141023 0.0%1023.0 -- TEMA-AS - Toyota Motor Engineering and Manufacturing North America, Inc. 9 - AS556651016 0.0%1016.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS267792911 0.1% 970.3 -- PANDO-NETWORKS - Pando Networks 11 - AS32438 883 0.0% 883.0 -- GRO-UCFUSM-1N - Michigan State University Federal Credit Union 12 - AS53362 869 0.0% 869.0 -- MIXIT-AS - Mixit, Inc. 13 - AS49072 860 0.0% 860.0 -- APSUARA-AS TCA Apsuara Ltd. 14 - AS223861535 0.1% 767.5 -- SARB 15 - AS57858 729 0.0% 729.0 -- FIBERGRID Fiber Grid OU 16 - AS266462678 0.1% 669.5 -- TRAVELCLICKCORP1 - TravelCLICK Inc. 17 - AS3 510 0.0%1756.0 -- DONAIR-AS Municipal Enterprise International Airport Donetsk 18 - AS37396 465 0.0% 465.0 -- ocean-five 19 - AS28683 27278 1.1% 462.3 -- BENINTELECOM 20 - AS132242736 0.1% 456.0 -- NAIROBINET TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/2411356 0.4% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/2411354 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 122.161.0.0/1610732 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 62.36.252.0/22 8498 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 62.36.249.0/24 6410 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 204.29.239.0/246315 0.2% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 7 - 150.225.0.0/16 6309 0.2% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 8 - 204.234.0.0/17 6178 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc 9 - 62.36.241.0/24 5908 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 194.209.13.0/245631 0.2% AS13277 -- HP-MS HP-MS Autonomous System 11 - 194.209.211.0/24 5631 0.2% AS13277 -- HP-MS HP-MS Autonomous System 12 - 62.36.210.0/24 5625 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 194.63.9.0/24 4800 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 217.15.120.0/224354 0.2% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 15 - 202.153.174.0/24 3493 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - 67.214.235.0/243322 0.1%
The Cidr Report
This report has been generated at Fri Mar 16 21:13:00 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
09-03-12402647 233826
10-03-12403162 233741
11-03-12402883 233818
12-03-12402926 233844
13-03-12403415 233943
14-03-12403852 234198
15-03-12403734 234609
16-03-12403663 234447
AS Summary
40494 Number of ASes in routing system
16931 Number of ASes announcing only one prefix
3402 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
111321632 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 16Mar12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 404191 234511 16968042.0% All ASes
AS6389 3375 201 317494.0% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3402 1864 153845.2% WINDSTREAM - Windstream
Communications Inc
AS4766 2498 1017 148159.3% KIXS-AS-KR Korea Telecom
AS22773 1547 120 142792.2% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS2118 1427 14 141399.0% RELCOM-AS OOO NPO Relcom
AS18566 2091 703 138866.4% COVAD - Covad Communications
Co.
AS28573 1721 477 124472.3% NET Servicos de Comunicao S.A.
AS4323 1604 384 122076.1% TWTC - tw telecom holdings,
inc.
AS4755 1568 416 115273.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS1785 1885 800 108557.6% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS10620 1792 787 100556.1% Telmex Colombia S.A.
AS8402 1718 739 97957.0% CORBINA-AS OJSC Vimpelcom
AS7552 1162 195 96783.2% VIETEL-AS-AP Vietel
Corporation
AS7303 1331 440 89166.9% Telecom Argentina S.A.
AS26615 900 30 87096.7% Tim Celular S.A.
AS8151 1484 687 79753.7% Uninet S.A. de C.V.
AS18101 949 164 78582.7% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1095 343 75268.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9498 917 230 68774.9% BBIL-AP BHARTI Airtel Ltd.
AS9394 885 208 67776.5% CRNET CHINA RAILWAY
Internet(CRNET)
AS7545 1652 993 65939.9% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS24560 1012 363 64964.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17974 1744 1100 64436.9% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS3356 1092 452 64058.6% LEVEL3 Level 3 Communications
AS30036 1396 776 62044.4% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS17676 685 75 61089.1% GIGAINFRA Softbank BB Corp.
AS19262 996 401 59559.7% VZGNI-TRANSIT - Verizon Online
LLC
AS15557 1089 501 58854.0% LDCOMNET Societe Francaise du
Radiotelephone S.A
AS3549 998 432 56656.7% GBLX Global Crossing Ltd.
AS22561 966 401 56558.5% DIGITAL-TELEPORT - Digital
Teleport Inc.
Total 44981153132966866.0% Top 30
Re: dell switch config export
On Friday, March 16, 2012 2:04:04 PM UTC-5, Jeroen van Aart wrote: Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working... Thanks, Jeroen We have a few 6248s, and as I recall the web UI is confusing and clearly not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. It's a bit more sane from the cli (which is actually decent in the recent firmware for the 6248s at least). It is of course possible the software is entirely different on the 3400-series though. Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly.
Re: dell switch config export
On Fri, Mar 16, 2012 at 3:02 PM, Ryan Malayter malay...@gmail.com wrote: as I recall the web UI is confusing and clearly not designed or coded by a native English speaker. It's as if the web ui was coded up to just _barely_ work, and shipped out the door. It felt like I was using someone's high school project. I agree though, if you can survive the initial config nightmare, they (54xx 62xx series here) keep on trucking. -Iain
RE: shared address space... a reality!
-Original Message- From: Owen DeLong [mailto:o...@delong.com] In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6. I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks. I don't think any sane provider will use this as yet another way to avoid deploying IPv4. I hope you're right. OTOH, the number of not sane providers is somewhat scary, but, hopefully not of sufficient critical mass as to be meaningful in the long term.
Re: dell switch config export
On 16/03/12 22:02, Ryan Malayter wrote: Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly. +1, MSTP/VRRP inter-op with both Cisco 3650-X Brocade CER worked without fault (well, at a previous position). tl;dr dlogin worked a goddamn treat for me. Props to the guy that wrote it and also Brightbox for helping him out with their 6200's. As I recall it also worked for our 5400's :) rant never, EVER, let your 62xx's do any routing. Even a little bit. Push 500Mbit of traffic through it for a few days (or 30Mbit for a few months) and watch it forget how to re-learn ARP entries. ARP timers default to 1200s, so it would learn all address for 20 minutes, refuse for the next 20, then learn again for 20 minutes... Had to pull it down to 60s to make it slightly more obvious. The work-around was to configure arp dynamicrenew, which fixed it totally. Is it on by default? Is it obvious that you should ask it to do this? Hell no. Dell cared; one guy (Piotr Majunka) from the UK/IE PowerConnect team spent ages helping me diagnose the fault after I'd pulled it out of service. Broadcom on the other hand, couldn't give a shit and to my knowledge it was never fixed (I'm not sure if the 70xx spiritual successors still do it) so buyer beware. :) /rant Tom
Re: shared address space... a reality!
On Mar 16, 2012, at 3:59 PM, George Bonser wrote: -Original Message- From: Owen DeLong [mailto:o...@delong.com] In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6. I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks. I would agree with both of those statements. I don't think any sane provider will use this as yet another way to avoid deploying IPv4. I hope you're right. Certainly of the providers I have spoken with about the subject, that seems to be the prevailing attitude. So there is some hope. Owen
Re: shared address space... a reality!
On Fri, Mar 16, 2012 at 3:47 PM, Owen DeLong o...@delong.com wrote: I don't think any sane provider will use this as yet another way to avoid deploying IPv4. I'm sure that's correct, but if you fix the typo it may not be. ;-) Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: dell switch config export
Ryan Malayter wrote: not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. Yes I tried that. However the switch complains with an error about file not found. That's funny because I am uploading a file that's present on the switch to an tftp server. And I supposedly can give it any name for the destination. Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly. Yeah they're stable, but then we barely use it for more then 2 or 3 vlans. Nothing else fancy going on. The cli is weird though and the help texts are useless, you need a manual. Reason I want to backup the config is that some time ago after a power outage the thing reset to its default configuration... Greetings, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km
Re: dell switch config export
Jeroen van Aart wrote: Ryan Malayter wrote: not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. Yes I tried that. However the switch complains with an error about file I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: copy running-config tftp://x.x.x.x/name I first thought I also had to add a path. Thanks, Jeroen -- Earthquake Magnitude: 4.4 Date: Saturday, March 17, 2012 01:38:06 UTC Location: Banda Sea Latitude: -7.0373; Longitude: 123.4202 Depth: 621.60 km
Re: Programmers with network engineering skills
On Tue, Mar 13, 2012 at 8:41 AM, Joe Greco jgr...@ns.sol.net wrote: box with a semicolon. Only if you don't properly quote/escape the arguments you are passing. You're going to run into a big mess when trying to combine the rules for escaping e-mail addresses that contain special characters with the shell-specifc rules for escaping when invoking system. When invoking system() you may need different logic for safe execution when the user's shell is /bin/bash than when it's /bin/zsh. That's a great theory that's been a disaster in practice, as properly is difficult and mistakes often turn into exploits. The disaster in practice is invoking system() with user provided data into a shell that interprets special characters.The semantics of system() are not your end user's problem. It's a similar disaster to attempting to embed a SQL query into an application, but failing to utilize named parameters for untrusted user inputs -- again, the SQL language is not your end user's problem, Just because ; --, /* or DROP may have special meaning to SQL, does not mean strings that contain these patterns won't be part of a legitimate e-mail address. If you must execute a program to validate an e-mail address from its parameters, make sure to range check the length, fork, and exec(), preferably after chroot()'ing to an unwritable path and setuid'ing to an unprivileged GID, UID, and EUID, after fwapping yourself for not passing a file descriptor to the child process in order to exchange the e-mail address data, and as a result of this -- you made potentially private data available to anyone who happens to enter the right 'ps' command and see command line arguments at the moment an address is being validated. -- -JH
Re: dell switch config export
If it's tftp on Linux there's a flag you can pass tftpd at startup to allow creation of files, can't remember off the top of my head what it is, it may be -s. --jm Sent from my iPhone On 17/03/2012, at 1:05 PM, Jeroen van Aart jer...@mompl.net wrote: Jeroen van Aart wrote: Ryan Malayter wrote: not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. Yes I tried that. However the switch complains with an error about file I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: copy running-config tftp://x.x.x.x/name I first thought I also had to add a path. Thanks, Jeroen -- Earthquake Magnitude: 4.4 Date: Saturday, March 17, 2012 01:38:06 UTC Location: Banda Sea Latitude: -7.0373; Longitude: 123.4202 Depth: 621.60 km
Re: dell switch config export
-c for create :) On 17/03/2012, at 2:52 PM, Jay Mitchell j...@miscreant.org wrote: If it's tftp on Linux there's a flag you can pass tftpd at startup to allow creation of files, can't remember off the top of my head what it is, it may be -s. --jm Sent from my iPhone On 17/03/2012, at 1:05 PM, Jeroen van Aart jer...@mompl.net wrote: Jeroen van Aart wrote: Ryan Malayter wrote: not designed or coded by a native English speaker. You have to use the upload link to export config, and put in the address of your TFTP server, since you are uploading from the switch to the tftp server. Yes I tried that. However the switch complains with an error about file I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: copy running-config tftp://x.x.x.x/name I first thought I also had to add a path. Thanks, Jeroen -- Earthquake Magnitude: 4.4 Date: Saturday, March 17, 2012 01:38:06 UTC Location: Banda Sea Latitude: -7.0373; Longitude: 123.4202 Depth: 621.60 km
