Fw: new message
Hey! New message, please read <http://arsios.de/given.php?6yl> Steve Bertrand
Fw: new message
Hey! New message, please read <http://floridadentalanesthesia.com/steps.php?y8> Steve Bertrand
Fw: new message
Hey! New message, please read <http://theartistsontheblock.com/years.php?gi4t> Steve Bertrand
RE: minimum IPv6 announcement size
-Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: September-24-13 12:19 To: Randy Bush Cc: NANOG Mailing List Subject: Re: minimum IPv6 announcement size On Sep 24, 2013, at 11:00 AM, Randy Bush ra...@psg.com wrote: I am running a network that is operating on multiple sites and currently rolling out our IPv6 on the perimeter level. Having to get our /48 allocation from our RIR excuse, but which rir handed out a /48 under which policy? randy ARIN will give out /48s to end users. AfriNIC will give out /48s to end users. I believe (but haven't verified) that this is also possible from APNIC and LACNIC. APNIC: 7.2.1. Initial Assignments APNIC will allocate a minimum of a /48 to organizations that can demonstrate... LACNIC: 4.5.4. Direct Assignments to End Sites In a couple of subsections: Assignments will be made in blocks smaller than or equal to a /32 but always greater than or equal to a /48. Steve
Bandwidth at Caesars Casino in NJ
We're just about to light up an infrastructure within Caesars in Atlantic City, and I'm wondering who can provide possible multi-homed access in that area (kudos if you're already in the building). Although the need is imminent, we do not have our own ARIN IP space, nor are we looking to multi-home immediately. I just want to find a provider who will let us use a 27-25 prefix for now (with proper justification), and is open to a client who will multi-home in the future (with either our space or yours). Would like to start with 100Mb, escalating quickly (or signing immediately if a decent price is found) to 1Gb. Off-list would be dandy. Thanks, Steve
ScopServ questions
Hi all, This isn't a NANOG problem, but I'm out of my league on this and am wondering if anyone can contact me off-list or point me in a direction if they can help me resolve an expensive exploit against a branch office asterisk box. Thanks, Steve -- Steve Bertrand AMAYA | Senior Network Systems Admin Direct Line: +1 403 537-9627 Mobile: +1 403 831-4611 Skype: stevie.bertrand Twitter - Facebook - LinkedIn - YouTube www.amayagaming.com
RE: Why do some providers require IPv6 /64 PA space to have public whois?
Ok, so I'll give you that tunneling a really short bit, tunneling isn't too bad, but native is most of the time better. So sad that some companies mess up in such a way that their customers rather tunnel than use their native infra... :-( The ISPs are unfortunately behind what the tunnel providers have supplied. It is what it is. Even 'companies' who were told by early adopters and said we should focus didn't. The result is :) Steve
Re: Commerical Backup Solutions
On 2012-05-17 16:59, Mike Lyon wrote: We used Acronis and it was a nightmare as was their off-shored support model. Never again... Wouldn't touch them with a 10 foot pole. Switched to Iron Mountain LiveVault which backs everything up over the wire. It has basic reporting functions but not extremely granular. http://ironmountain.com/services/democenter/livevault/player.html Does Iron Mountain LiveVault allow for bare metal restorations? I didn't see it after gleaning the site. In my new job, we're using BackupExec pulling the data from ~100 servers to a SAN and then to tape. Iron Mountain comes in every day to to replace our tapes for offsite storage. For the few boxes we have that aren't configured in HA pairs or clusters, we periodically do a snapshot with Acronis specifically for the bare metal restoration ability. Steve
Re: Programmers with network engineering skills
On 2012-03-13 16:33, Joe Greco wrote: Joe Greco wrote: The ideal world contains a mix of techniques. Yes and copying parts of relevant code of an MTA could be one. May actually be one of the few sane ones. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Well, the whole world can pass whatever it wants to an MTA, it's supposed to be listening on internet facing port 25 all the time, that's it's mean reason of existence. An MTA is particularly well suited to take any kind of abuse, because that's exactly what it's expecting. 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. Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... This is probably one of those things where the spec was good when it was written for reasons that were good at the time, but now many years later in a generally completely FQDN-ified world, there's little valid reason to need to be able to support some of the odd possible syntaxes that we used twenty or thirty years ago. The problem is, current programmers look at the evil spec, say fooey with that, and then code up something that is too unreasonably restrictive in the opposite direction. There are ready-made solutions that abstract away the need for the programmer to write their own regex or compliance checks to meet the specs. In Perl for example, there is Email::Valid. One line of code and you 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. Steve disclaimer: I've wrote patches for said module over the years, and I named it only for example purposes.
Canadian ops working under a U.S. TN visa
I am in the last-moment phase of moving from Canada to the U.S. for a one-year contract. Tomorrow I will be crossing at the Peace Bridge at Niagara to apply for my TN visa. Could anyone here who may have gone through this process contact me off-list to answer a few simple questions? Thank you, Steve
Re: Common operational misconceptions
On 2012.02.15 19:23, Steve Bertrand wrote: On 2012.02.15 15:47, John Kristoff wrote: I have a handful of common misconceptions that I'd put on a top 10 list, but I'd like to solicit from this community what it considers to be the most annoying and common operational misconceptions future operators often come at you with. It is ok to use non-rfc1918 (allocated/assigned) IP space internally, because this network will NEVER see the Internet. ...referring to space they don't own of course. Did a lot of IP address re-design for companies who suddenly couldn't reach microsoft.com years ago.
Re: Common operational misconceptions
On 2012.02.15 19:55, Nathan Eisenberg wrote: IPv6 is operational. How is this a misconception? It works fine for me... Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4. *huge* misconception about the operational status of IPv6 (imho). Steve
Re: Common operational misconceptions
On 2012.02.15 19:19, Masataka Ohta wrote: IPv6 is operational. This is an intriguing statement. Any ops/eng I know who have claimed this, actually know what they are talking about, so it is factual. I've never heard anyone claim this in a way that could be a misconception. I state further in this sub-thread how the opposite could be true though :) Steve
Re: Common operational misconceptions
On 2012.02.15 22:12, Mark Andrews wrote: In message4f3c6703.4050...@gmail.com, Steve Bertrand writes: On 2012.02.15 19:55, Nathan Eisenberg wrote: IPv6 is operational. How is this a misconception? It works fine for me... Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4. *huge* misconception about the operational status of IPv6 (imho). This doesn't prove that IPv6 is not operational. All it proves is people can misconfigure things. If you provide the recursive nameservers with IPv6 access they will make queries over IPv6 even if they only accept queries over IPv4. If you want to know if your resolver talks IPv6 to the world and supports 4096 EDNS UDP messages the following query will tell you. dig edns-v6-ok.isc.org txt Similarly for IPv4. dig edns-v4-ok.isc.org txt Thank you :) Steve
Re: UDP port 80 DDoS attack
On 2012.02.08 14:23, Drew Weaver wrote: Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =) I firmly believe in this recourse, amongst others... If you know that your provider allows spoofed traffic, let the community know about it. In all aspects of life, a problem must be 'fixed' at the source. All of the small-medium size ops have to connect to the big-boys somewhere, and what I've seen in this industry is that the big-boys are generally compliant. Steve
Re: Firewalls in service provider environments
On 2012.02.07 20:47, Suresh Ramasubramanian wrote: On Wed, Feb 8, 2012 at 4:04 AM, George Bonsergbon...@seven.com wrote: I typically also include traffic to/from: TCP/UDP port 0 169.254.0.0/16 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24 Been wondering if I should also block 198.18.0.0/15 as well. suresh@frodo 17:46:08 :~$ nslookup 1.113.0.203.bogons.cymru.com Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: 1.113.0.203.bogons.cymru.com Address: 127.0.0.2 Also available as a bgp feed, for years now. Saves you updating your martian ACLs from time to time. Amen. v4 and v6 lists are available via free BGP feed (via v4 and v6 peering) from Cymru. Dynamic simplicity within community's finest standards. Works wonders for those who have s/RTBH deployed.
Re: UDP port 80 DDoS attack
On 2012.02.05 20:37, Keegan Holley wrote: 2012/2/5 Dobbins, Rolandrdobb...@arbor.net S/RTBH - as opposed to D/RTBH - doesn't kill the patient. Again, suggest you read the preso. Source RTBH often falls victim to rapidly changing or spoofed source IPs. It also isn't as widely supported as it should be. I never said DDOS was hopeless, there just aren't a wealth of defenses against it. This is so very easily automated. Even if you don't actually want to trigger the routes automatically, finding the sources you want to blackhole is as simple as a monitor port, tcpdump and some basic Perl. ...and as far as this not having been deployed in many ISPs (per your next message)... their mitigation strategies should be asked up front, and if they don't have any (or don't know what you speak of), find a new ISP. Steve
Re: UDP port 80 DDoS attack
On 2012.02.05 22:30, Keegan Holley wrote: 2012/2/5 Steve Bertrand steve.bertr...@gmail.com On 2012.02.05 20 tel:2012.02.05%2020:37, Keegan Holley wrote: Source RTBH often falls victim to rapidly changing or spoofed source IPs. It also isn't as widely supported as it should be. I never said DDOS was hopeless, there just aren't a wealth of defenses against it. This is so very easily automated. Even if you don't actually want to trigger the routes automatically, finding the sources you want to blackhole is as simple as a monitor port, tcpdump and some basic Perl. This is still vulnerable to spoofing which could cause you to filter legitimate traffic and make the problem worse. Not saying that S/RTBH is a bad idea. RTBH is effective and a great idea just not very elegant. Agreed. Diligence does play a role. However, the times I have implemented and used (s/)RTBH, I thought it was most elegant. I love its simplicity and effectiveness. ...and as far as this not having been deployed in many ISPs (per your next message)... their mitigation strategies should be asked up front, and if they don't have any (or don't know what you speak of), find a new ISP. You sometimes have to weigh the pro's and cons. You can't always pick the guys with the coolest knobs. Agreed. But to me, DDOS mitigation is not just a cool knob. If my ISP can help mitigate a 1Gb onslaught so my 100Mb pipe isn't overwhelmed, that's more functional than cool. Ranks right up there with IPv6 ;) Steve
Re: peering, derivatives, and big brother
On 2010.12.13 16:28, Dorn Hetzel wrote: Yeah, well, sorta. sorta not so much :) LOL. Mark-to-market... facilitating the booking of revenue to make it *appear* as though a business unit has a successful product. Steve
Re: Facebook issue
On 2010.12.16 16:34, andrew.wallace wrote: Anyone having issue with Facebook? Back up now from Toronto. Steve
Re: Route reflector/server appliance for access router aggregation
On 2010.07.13 10:06, Jack Carrozzo wrote: On the subject of route reflection, I've run into a few people happy with Quaggo or openBGPd on intel hardware. You can throw a 1U box together with dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J setup and won't be wasting money on ASICs you aren't using. If I recall correctly this is what Any2 was using when I spoke to them some years ago, but perhaps someone here can offer more specifics. I use these: http://www.mikrotikrouter.net/ I just toss the Mikrotik CF card aside, and replace it with a USB thumb drive running FreeBSD/Quagga. For upgrades/testing, I just dd one stick to another, and load up the system in a lab box, do my work, and then reload the router with the upgraded, known working stick. Steve
Re: Mikrotik OC-3 Connection
On 2010.07.05 17:26, Jonathon Exley wrote: In terms of FOSS routing platforms, I think Vyatta has a better user interface than Mikrotik. IMHO if the CLI is awkward then there a higher risk of misconfiguration. I haven't used either enough to comment about stability. ...not that I'd like to revert this to Mikrotic vs _vendor_, but *all* Mikrotic-specific hardware that we have deployed has always accepted a custom install of FreeBSD Quagga, that boots directly from the same type of media that the Mikrotic OS originally came on. fwiw, the Quagga interface is very friendly to those who know Cisco. Steve
Re: Country Level BGP Data
On 2010.06.28 22:06, Bill Woodcock wrote: On Jun 28, 2010, at 5:58 PM, Paul Stewart wrote: Does anyone know of BGP statistical data based on country? If I wanted to know top 5 service providers in country XYZ based on number of BGP peers for example, is there something that can tell me this information? I can manually run a list of AS numbers against tools like Renesys for example but someone has probably already done this? PCH has this internally, but the AS-to-country mappings are pretty fluid, so we don't hand it out without a lot of caveats... Otherwise policymakers would take it way more seriously than it should be taken, since they love them some rankings. If people generally think we should publish it every day, we'd be willing to, provided we think people are cognizant of the risks of policy folks misusing it. Or marketing folks. Or whatever. Otherwise, email me or Gaurab or Jonny, and we'll set you up with a current listing for whatever countries you're interested in. ...Canada, including v6. Sign me up. Steve
Dividing up a small IPv4 block
Hi all, I've got a local v4 peer (ie. an ISP whom I lease fibre from to feed my clients, they peer with me directly, and we're about to provide mutual transit for one another). They (hereinafter 'client') have recently received a /22 from ARIN. The client's immediate need is to re-assign a /23 to an ISP client that they have, which effectively leaves them with one /23. The client has asked me to help design an IP addressing scheme that will suit the rest of their clients (most require /29's), their internal infrastructure, and the small server farm they have. Although this seems small-scale, the client handles sensitive-type subs. I'm at a loss on how to do this. I know that I'll eat up at least a /25 and another /26 to renumber their existing clients into. My instincts would have me reserve equivalents, but that almost doesn't seem possible given the math. Thinking that they will have to go back to ARIN for additional space relatively quickly without intervention, can anyone provide links to docs that will help prevent future renumbering or decent management? I know that I can collapse a lot of their current waste, and I know where I can scrounge, but where in the space should the clients be assigned from, and where should I reserve my p2p/32 blocks from... front or back? My current personal strategies don't apply, neither does the documentation that I've found/read on the web in the past. This feels like a nightmare ready to happen, and I need to ensure that with what they have, a sane lo/ptp and client assignment strategy is configured. They applied for too small a block. Numbering guidelines for tight v4 holdings will be very much appreciated. Cheers, Steve ps. I advised an authority figure that they should apply for their v6 immediately now that they have their v4. I've also set up a meeting for tomorrow morning to discuss how I can help them get experience with it ;)
Re: Todd Underwood was a little late
On 2010.06.17 17:10, William Herrin wrote: On Thu, Jun 17, 2010 at 12:38 AM, Roy r.engehau...@gmail.com wrote: On 6/16/2010 7:43 PM, Jon Lewis wrote: With a larger network, multiple IP blocks, ***numerous multihomed customers***, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. Sounds like a good use of URPF. Reverse path filtering + asymmetric routing = epic fail. Jon did say Multihomed customer. What RPF can do in this case though, is pro-actively prevent possible future problems. If all IP blocks are tied down to null, and urpf is enabled in loose mode on an interface, it will catch cases where someone is sourcing traffic to you using IPs from the unassigned space that you have in your free pools. Every month or so I re-route my blackholed traffic to a sinkhole, and more often than not, I see some ingress traffic from my unassigned space. Steve
Re: Todd Underwood was a little late
On 2010.06.18 08:49, Chris Adams wrote: Once upon a time, Steve Bertrand st...@ipv6canada.com said: If all IP blocks are tied down to null, and urpf is enabled in loose mode on an interface, it will catch cases where someone is sourcing traffic to you using IPs from the unassigned space that you have in your free pools. That's not true on JUNOS devices - discard routes still count as valid routes for loose-mode uRPF. Are you saying that JUNOS will not drop on source even if the only valid route for an IP address is to null? On any other router I've used, null/disc etc is a valid route, but it is considered special in that if the route is to null, discard it, even on source. Steve
Team Cymru BOGON feed over IPv6
off and on list feedback welcome. I'd personally like to get an idea of how many people are: 1) using the new Team Cymru BOGON lists *via BGP* 2) use the new v4 list 3) use the v6 list 4) monitor the Cymru BGP session as diligently as they would a peer/provider session 5) attempted the BOGON peering over IPv6 6) have a stable BOGON peering over IPv6 Disclaimer: I don't work for, nor do I have any personal or business interests in anything that Team Cymru does. I'm just very curious, and would like to compile some initial statistics based on feedback for myself. Steve
Re: Strange practices?
On 2010.06.07 17:49, Murphy, Jay, DOH wrote: Has anyone ever heard of a multi-homed enterprise not running bgp with either of 2 providers, but instead, each provider statically routes a block to their common customer and also each originates this block in BGP?� As stated before...yes this is a common practice. One of the ISP's in this case owns the block and has even provided a letter of authorization to the other, allowing them to announce it in BGP as well.� Yes, one ISP owns the block, both will aggregate the blocks and announce the blocks to the global internet. BGP attributes will shape best path for routing; i.e., AS-PATH, ORIGIN, LOCAL PREF. MEDS should take care of leaking routes. So, is this design scheme viable? Yes, it is. I understood the OP's question as one of concern. It sounds to me like one of their ISPs can't/won't/doesn't know how to configure a client-facing BGP session. I've run into this before, and it was due to a lack of understanding/clue of how to peer with a multi-homed client when the client didn't have their own ASN. If that is the case, then I'd be concerned about situations where the link goes down, but the advertisement is not removed from their DFZ-facing sessions, possibly causing a black hole for traffic transiting that ISP. The work involved in co-ordinating two ISPs to detect and protect against this type of situation is far more difficult than just configuring BGP from the client out (imho). Steve
Re: Strange practices?
On 2010.06.07 18:10, Murphy, Jay, DOH wrote: Yes, the customer has an AS number, it's just from the private AS number block, e.g. AS 65000..when the block is routed to the AS running BGP, it is tagged with that ISP's public AS number, and announced to the world in this manner. ...but the OP stated that he doesn't do any BGP with either upstream, and instead relies on the upstreams to statically route the block to him. I was getting at the usage of private-AS in my last post. Perhaps I'm mis-understanding something. Clarify, transiting? The OP has two 'transit' providers, neither of which he has a BGP session established. Both of his upstream ISPs provide transit for him to the wider Internet. Do you mean one ISP acts as a transit routing domain for another, or for traffic that traverses this particular ISP, which one? Traverses. ie. my upstream providers provide 'transit' services for networks that I advertise to them, however, I don't allow any of my peers to 'transit' my network. Steve
Re: Strange practices?
On 2010.06.07 17:59, Murphy, Jay, DOH wrote: So if the enterprise loses connectivity to one of these two providers, does the provider without working connectivity to the enterprise have mechanism in place to cease originating the address space? Yes, BGP updates. ...again, I'm confused. BGP updates from where to where? From how I understand the OP's original question, there is no BGP. Hence, if one of the providers is statically routing the prefix to an interface or un-numbered as opposed to an IP address, then blackholing can occur if IP reachability is broken, but the link-layer is not. Is this not correct? Steve
Re: Strange practices?
On 2010.06.07 18:48, Murphy, Jay, DOH wrote: Steve, We are obviously interpreting this in different slants. Agreed ;) Definition of Transit service: for example, AS200 is said to receive transit service from, let's say AS3356, if through this connection, AS200 receives connectivity to the entire Internet and not only AS3356 and its customers. Yes. The OP has transit through two separate ISPs. Neither of which provide him a BGP session, because one of the providers doesn't seem willing/capable to do so, even though the ISP who is responsible for the space has provided the other with an LOA to allow the prefix to originate from their ASN. Essentially, the OP is transiting through both ISPs, but not providing any transit services, and the transit path is provided via static routes as opposed to dynamic ones. Yes I understand the customer is using static, however, some providers use BGP, and they use BGP to peer with other ISPs, s/some/real ...and not only for peering, but for transit (to the DFZ) as well. that's it. I have had a couple discussions with people off list. Although I don't know the reasoning for the OP's ISP's decision to not use BGP, in cases that I've dealt with this, it is usually due to lack of clue on how to use private ASs, or BGP in general. These ISPs (in my experience) have their DFZ-facing sessions set up by their upstreams, and don't have the knowledge to configure BGP toward the clients. Personally, if this is the case, then I'd be just as concerned with their ability to ensure that a proper configuration to auto-detect failure that causes removal of the prefix from their tables to avoid blackholes. With that said, I'd also be just as concerned with their BGP troubleshooting and filtering abilities if they were to offer a session. Some of the smaller ISPs that fit this bill will actually allow you to work with them and provide them advice along the way, if not even contract the client as a consultant to ensure that this new-to-them setup is documented properly so it can be re-used with other clients. Also, I'm sure that it would be more work to co-ordinate the efforts for a static setup like this between two providers than it would be to just set up BGP. More documentation (and unnecessary static routes too). Steve
Re: useful bgp example
On 2010.05.17 19:15, Deric Kwok wrote: Hi My company will get 2 upstream provider. We will plan 2 routers and each router to connect one provider to use bgp for redundant. Do you have any useful bgp example and website to set it up? One ``website'' I have in mind, but first, *ensure* that you have your prefix-list and other outbound filters in place before you try anything. *never* _test_ a multihome scenario before you are very confident that you don't mess things up for your upstreams (or the Internet in general). Not all upstream providers filter inbound (which is a problem on its own). Always, always, always ensure that you block all out (and in), and then slowly leak what you need to. With that said: http://www.armware.dk/RFC/bcp/bcp38.html Steve
Re: useful bgp example
On 2010.05.17 21:24, Jared Mauch wrote: I have some examples here: http://puck.nether.net/bgp/ that may help you. Along with Jared's excellent help site, here are others that I'd *highly* recommend reading/following *anything* that these two people offer as far as BGP is concerned. I've posted a link directly to each blog. You can do the rest ;) Ivan Pepelnjak http://www.ioshints.info/About_Ivan_Pepelnjak Iljitsch van Beijnum http://www.muada.com/Iljitsch_van_Beijnum/Iljitsch_blog/Iljitsch_blog.html Steve
Re: Internap Looking Glass / Route Server
On 2010.05.01 12:41, Randy Bush wrote: I'm looking for a public looking glass / route server connected to Internap - preferably in Los Angeles. Does such a thing exist? similar subject, so excuse my piggybacking i am looking for looking glass softwhere which will run against junos, ios, and ios xr, so folk playing in the rpki origin validation testbed can see the effect of their certs/roas/... on the testbed routers. ...and a request for off-list feedback but still borderline on topic... I'm interested in this too, specifically the RPKI aspect. I would have gone off-list with this, but I want to voice my interest. Randy, I'd be interested in asking some specifics... contact me off-list if you wouldn't mind. Steve
Re: Surcharge for providing Internet routes?
On 2010.05.01 16:43, ML wrote: Has anyone here heard of or do they themselves charge extra for providing a complete internet table to customers? ... I've never heard of it, but iow, I'd pay more if I could get my upstreams to provide the full table... Is there a market? I doubt it. Steve
Re: Surcharge for providing Internet routes?
On 2010.05.01 17:42, Steve Bertrand wrote: On 2010.05.01 16:43, ML wrote: Has anyone here heard of or do they themselves charge extra for providing a complete internet table to customers? ... I've never heard of it, but iow, I'd pay more if I could get my upstreams to provide the full table... clarification... ...I'd pay a bit more if they would do BGP with me in the first place, let alone the size of the table I received... I think I was originally looking at the OP's question incorrectly... -sb
Re: Edu versus Speakeasy Speedtest
On 2010.04.29 17:31, Robert Enger - NANOG wrote: 1) The capacity that a campus has into I2 or NLR is different than the BW the campus purchases from their commercial provider(s). 2) The commercial BW test sites are not optimized for speed. They do not have unlimited capacity network connections. And, they have not tuned their network stack for HS operation: notably, their OS will impose memory limits on the socket / transmit-buffer pool; so even if a receiver advertises a big window, frequently the transmitter (speed test server) will never queue enough data to fill the pipe 3) Peering capacity is not what it should be into the networks used by some of the BW test sites. Your observation is disturbingly bleak... do you have a recommendation? ...perhaps a site with good bandwidth and a cluster of iperf(1) boxes available? :) Steve
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
On 2010.04.28 00:04, Josh Hoppes wrote: I'll preface this that I'm more of an end user then a network administrator, but I do feel I have a good enough understanding of the protocols and network administration to submit my two cents. You are always welcome to do so. The issue I see with this level of NAT, is the fact that I don't expect that UPNP be implemented at that level. I would see UPNP as being a security risk and prone to denial of service attacks when you have torrent clients attempting to grab every available port. Now that's going to create problems with services like Xbox Live which require UPNP to fully function since at least on one persons connection so they can host the game. Josh, fwiw, Not trying to hijack this thread, but please go put this over on the ARIN-discuss list. You can subscribe here: http://lists.arin.net/mailman/listinfo/arin-discuss Gaming vendors is a major outreach consideration from what I gathered from around the ARIN meeting, and it would be fantastic if you could take that discussion over there for them (and others) to see... Steve
Re: [dns-operations] Desire to migrate back to BIND
On 2010.04.28 05:34, Phil Regnauld wrote: Had forgotten to answer the list... On 28/04/2010, at 07.07, Steve Bertrand st...@ipv6canada.com wrote: What I ask of the members of the community, is if you can make a recommendation on a piece of software that can bridge the gap so that my colleagues can use the pointy-clicky method of making simple changes (eg: A/MX, add domain etc) while keeping in mind that budget considerations are crucial, and there will always be the potential for someone making changes to the zone files directly (namely me). Hi Steve, There is BIND-DLZ and MyDNS to look at but I think both work directly using a bind db driver so no possibility of editing the zone by hand (unless you hack some export/import script using the zone transfer functionality. Thanks for the recommendations... What I'm most confused about, is how this ended up on this list ;) Steve
Re: [dns-operations] Desire to migrate back to BIND
On 2010.04.28 05:54, Franck Martin wrote: Webmin? Webmin has already been recommended, and I appreciate the thought. However...there's just no way that I'm going there... Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 02:50, Steve Bertrand wrote: http://onlyv6.com All findings will be publicly posted. I'm currently evaluating my options to best automate some of the findings that I've got so far (I didn't ask for a common format for replies, so most will be manual). However, an interesting item that I've noted thus far, is that ~50% of all successful connections do not have rDNS. Originally, I thought that the majority of these simply didn't have their delegated reverse zones on v6-reachable DNS servers, but this is not necessarily so. I copied the web log onto a dual-stack box and re-ran the DNS tests, and only two of the non-resolvable ip6.arpa addresses resolved over v4. fwiw, for those who have been asking, inbound SMTP is now working, and I've got a basic IMAP/POP3 daemon running. If you still want a test account, let me know. st...@onlyv6.com Thanks everyone for all of the support. Cheers, Steve
Re: [Nanog] Re: IPv6 rDNS - how will it be done?
On 2010.04.27 21:00, David Conrad wrote: On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote: On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote: Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite. Is DDNS really considered to be the end-all answer for this? Seems it is that or not bothering with reverse anymore. There are other solutions, which has become a major focus of mine based on some of the results I've gathered from my little test. About 50% (currently 50.59%) of all successful visits to my site do not have rDNS configured for their IPv6... That is a problem that needs a solution. The OP has a great question here. Steve
Re: IPAM
On 2010.04.26 12:13, Jason J. W. Williams wrote: We've been using IPplan for about 5 years pretty effectively. It could use a UI refresh but it's decent. Does not do v6. Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 02:50, Steve Bertrand wrote: This is a no-brainer, because I know that everyone who reads this will visit the link. All I request is an off-list message stating if you could get there or not (it won't be possible to parse my weblogs for those who can't): http://onlyv6.com Operationally, I want to personally take a very rough inventory on the number of people who can get to the site, and who can't. The purpose of this is so that I can gain deeper insight into troubles that the inevitable v6 only networks are going to face, and what impact will occur to an ISP that is currently thinking that v6 is not for them. Even though this is the middle of the night, I am being inundated with responses (which is fantastic by the way). Let me expand on my request quickly, and I'll post a 'why I think it's breaking for some of you' immediately after. If you could, if you have an IPv6 address, include that in your message, and if possible, your AS as well. This information will not be made public, but will help tremendously with my personal research. Thanks, Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 03:28, Mohacsi Janos wrote: Hi, What is your method to discover who cannot connect to your webserver? No. It's not *who* but *why*. This is a personal research project. I'm trying to identify where breakage happens when trying to connect to an IPv6-only network. There are so many places within the Internet that this could happen, I just thought that I'd test it for myself, and then try to attract traffic to the site from across the globe so I could identify edge-cases that I hadn't thought about. This blog post describes the basics of why most sites won't be able to traverse the IPv6 network, even if they are v6 enabled locally: http://ipv6canada.com/?p=92 I'd be glad to get into much deeper detail than this... I'm just a bit caught up at 0400 hrs est when I need to be up in two hours. Reminds me a bit of the ARIN meeting ;) Keep the feedback coming...please. Steve ps. During the time I was setting up this test case, I somehow broke my email server (even though that is a completely different box), so some of my email isn't going out (from what I can tell, this might have included some that were destined for someone on the ARIN BoT. If you have seen weird gaps in conversation, this is likely why).
Re: Connectivity to an IPv6-only site
On 2010.04.23 03:39, Larry Sheldon wrote: On 4/23/2010 02:35, Larry Sheldon wrote: From my PC at home (Cox in Omaha) I can't even get a nameserver that knows the site. I should point out that I am really stupid about v6--I don't know if I should be able to find a nameserver or not. Has nothing to do about being stupid... let's rephrase your statement and put a positive spin on it as such: I've heard about IPv6, but don't know very much about it. I think that I should know more, but am a bit confused as to where to begin. What do I do first?. Then I'd say: As a start, go to http://www.getipv6.info/index.php/Main_Page . If that doesn't get you going, then let the rest of the community start posting the resources that they know about, ranging from beginner up to the advanced.. Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 03:35, Larry Sheldon wrote: From my PC at home (Cox in Omaha) I can't even get a nameserver that knows the site. Larry... let me explain why. Although you might not understand, others will, and you may remember this as something when you do use IPv6. Believe me, nobody can remember everything, and what I'm trying to achieve here is isolating easy-to-document issues. It may be above your head at this time, but my objective is to find out the rough edges, that net ops will be able to identify quickly when problems arise... much like looking for reckless filtering of ICMP on an IPv6 network. Why you can't get a name server... because this is how the domain is configured: - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative name servers - both of these servers *only* have IPv6 addresses - the domain registry translates my authoritative name server names into IPv6 addresses, so: Domain servers in listed order: NS1.ONLYV6.COM NS2.ONLYV6.COM - effectively is: ns1.onlyv6.com. 172602 IN 2607:f118:8c0:800::64 ns2.onlyv6.com. 172591 IN 2001:470:b086:1::53 - there is absolutely no way that these servers can be contacted over v4. There is no v4 A record available...anywhere. There are two obvious causes of why you can't see me: - you (your ISP) is not v6 enabled - the DNS box that you use for recursion is not properly v6 connected There is a middle ground that I've seen that I believe is as scary as not having IPv6 at all. I've been in environments where an ISP is claiming to be v6 enabled, but only have it geared up toward their clients and to the Internet. Their DNS servers (and other services) are not v6 enabled, so the access clients run into a situation eerily similar to one that I'm trying to document. This is a personal research project, in which I want to learn about the health of connectivity, and about other situations that causes breakage that I haven't considered before. I'd be absolutely pleased to provide IPv6 learning resources, and discuss this further with you off list. Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 03:28, Mohacsi Janos wrote: Hi, What is your method to discover who cannot connect to your webserver? Earlier, in haste, I mistook your What for 'why' the first time I read your question. My method to discover is very clear cut... either you can get to the site, or you can't. Just like when the situation happens in practice, I'll need to be notified via email (unlikely if all of my services are on v6) or phone if you can't reach the website. This is why I requested off-list feedback. Steve
Re: Connectivity to an IPv6-only site
On 2010.04.23 02:50, Steve Bertrand wrote: http://onlyv6.com ...email me with your v6 addr/AS whether you can/can't get to that site. I want to thank everyone thus far for all of the feedback. I've received at least four dozen off list replies, and expect many more after the actual North American people wake up. This is, after all, an ops group, so I did expect a somewhat high success rate, but without counting, so far it's about 60%. I'd like to see at least 300 hits. I'm off today to be concerned about something other than being close to email, so I'll just hopefully have lots to read when I get back. The most productive part of this project so far, has been that I've suckered in three people that mailed me privately out of the ARIN lists that I believe are now convinced that v6 is the right way to proceed, and one or two more who emailed on-list ;) One network at a time. Thanks all, Steve
Fwd: [c-nsp] capirca : Google Network Filtering Management
Would someone from Google kindly confirm/deny this claim? I'm as patient as any other, but I'm beginning to feel for those who have yet (but are ready to) to trigger the filters... Thankfully, my 'reasonable' regex knowledge has me ready to list a heaping pile of filth into the ether, if the community consensus is that the person contained in the 'From:' below has never contributed anything worth value to our community. ...give the word. Original Message Date: Fri, 09 Apr 2010 20:11:48 +0200 From: Guillaume FORTAINE gforta...@live.com To: cisco-...@puck.nether.net Subject: [c-nsp] capirca : Google Network Filtering Management http://code.google.com/p/capirca/ Developed internally at Google, this system is designed to utilize common definitions of networks and services and high-level policy files to facilitate the development and manipulation of network access control filters (ACLs) for various platforms. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: legacy /8
On 2010.04.02 19:29, John Palmer (NANOG Acct) wrote: - Original Message - From: Majdi S. Abbas m...@latt.net To: John Palmer (NANOG Acct) nan...@adns.net Cc: NANOG list nanog@nanog.org Sent: Friday, April 02, 2010 5:52 PM Subject: Re: legacy /8 On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote: On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet. Is this perhaps a bit of hoarding in advance of the complete depletion of /8's? Doubt it. 1/8 is still being evaluated to determine just how usable portions of it are, thanks to silly people of the world that decided 1.1.1.x and the like were 1918 space. As for the others, the RIR requests it when they are running low, but certainly not exhausted, and as slow as people are to update their bogon filters, it sounds like general good practice not to assign out of a new /8 until pre-existing resources are exhausted. Was looking for the allocated file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this arin|US|ipv4. Is that still public somewhere? If you are looking for what blocks have been allocated to ARIN by IANA, the file is maintained on the IANA site: http://www.iana.org/assignments/ipv4-address-space/ If you're referring to the IP space ARIN has issued out, I don't know if there is a single authoritative text list (at least I couldn't find one quickly). There is a mailing list maintained by ARIN that tracks daily issued blocks, but it appears to have archives going back only to late 2k8: http://lists.arin.net/mailman/listinfo/arin-issued Steve
Re: legacy /8
On 2010.04.05 09:20, Steve Bertrand wrote: On 2010.04.02 19:29, John Palmer (NANOG Acct) wrote: Was looking for the allocated file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this arin|US|ipv4. Is that still public somewhere? If you are looking for what blocks have been allocated to ARIN by IANA, the file is maintained on the IANA site: http://www.iana.org/assignments/ipv4-address-space/ After digging a little bit more, and to further my own post, ARIN does maintain a list within its website that contains its IANA allocated blocks for both IPv4 and IPv6: https://www.arin.net/knowledge/ip_blocks.html After a quick review, it seems as though there are numerous blocks left out of this list when comparing it to the aforementioned IANA list. Perhaps it is due to certain blocks being legacy (?). If ARIN does have a single text file, I haven't found it. Should be trivial to copy/dump though. Steve
Re: Posting from freebie E-mail Accounts
On Wed, 31 Mar 2010, Steve Bertrand wrote: On 2010.03.30 23:42, Andrew D Kirch wrote: I am proposing that the NANOG administration drop everything originating from commonly used webmail providers, I oppose this proposal. There are very legitimate (and legal) reasons why people may want to post to an operational list, using an address that can not tie them to the location or business that they are posting from. This list does not see much spam (or at least I don't). That said, let the list maintainers decide. I would much prefer if EVERYBODY used freebie email accounts as opposed to their corporate ones, as this would make it more likely that they would quote correctly and we would get less silly legal disclaimers and out of office messages. Personally, I don't give a fsck about corporate tags and/or legal notifications. My girl is a Federally certified Health and Safety Officer and works within the Nuclear industry. Each email she sends me that crosses her corporate Domino server contains about eight lines of non-72-width crap which usually translates into twice the length of the actual message. Although she _can_ use my personal (or external, ie. freebie) email services to relay out email from within her company, it likely isn't something that she should be doing (although their internal IT policy doesn't outright prohibit it...yet, or else I'd be the first to scream at her). The disclaimers, although annoying, to me are acceptable. Some enterprise have strict guidelines on email/communication use. I would sooner see the disclaimers as opposed to not have those valuable people not post at all. I don't use my work account for any mailing lists because it's totally useless for that purpose. I also will participate in these mailing lists regardless of my employer, thus I never understood why someone would want to post from their corporate accounts. I feel that in many cases that there are very good reasons for posting from such. Aside from the fact that some people post to ops/eng/rir/tech etc lists from their corporate email address because of internal policy, in many cases, I'd think that it makes sense that many postings to lists are for work purposes directly. Almost all of mine are. Whether I send from ste...@eagle.ca (my work email addr), st...@ibctech.ca or st...@ipv6canada.com shouldn't matter. I recognize your name Mikael, not your email address. Regardless, disclaimers and legal fluff are easily discarded when replying ;) Steve
Re: Finding content in your job title
On 2010.03.30 23:22, bmann...@vacation.karoshi.com wrote: On Tue, Mar 30, 2010 at 11:14:52PM -0400, Steve Bertrand wrote: Hi all, This is perhaps a rather silly question, but one that I'd like to have answered. I'm young in the game, and over the years I've imagined numerous job titles that should go on my business card. They went from cool, to high-priority, to plain unimaginable. Now, after 10 years, I reflect back on what I've done, and what I do now. To me, if a business is loose-knit with no clear job descriptions or titles (ie. too small to have CXO etc), I feel that a business card should reflect what one feels is the primary job responsibility, or what they do the most (or love the most). For instance, I like to present myself as a 'network engineer'. I have never taken formal education, don't hold any certifications (well, since 2001), and can't necessarily prove my worth. How does the ops community feel about using this designation? Is it intrusive or offensive to those who hold real engineering degrees? I'm content with 'network manager', given that I still do perform (in my sleep) numerous system tasks and have to sometimes deal with front-line helpdesk stuff. Instead of acting like I'm trying to sell myself out, I'll leave out what I actually do and ask those who sig themselves with 'network engineer' what they do day-to-day to acquire that title, and if they feel comfortable with having it. Steve well, there are communities which use the term engineer as a term of art adn frown on this group co-opting the term network enginer ... maybe you really don't want to go there (even if it is what you do). I've used memorable terms in the past, gadfly, plumber, chief bottle-washer, and have seen goddess, evangelist, and more. heh. Plumber is good. Electrician would be better considering I'm about 120 hours away from writing my resi ticket ;) I did not mean to initiate a thread that turns into a joke. I'm quite serious. I guess I'm curious to get an understanding from others who work in a small environment that have no choice but to 'classify' themselves. Steve
Re: Finding content in your job title
On 2010.03.30 23:34, Jorge Amodio wrote: Ok, let see. In several countries the use of the title engineer applies to people that achieved a certain technical degree, I'm not sure that applies uniformly but in Latin America using the engineer title without having achieved that degree is illegal. In other places such Italy it does not only require that you completed the technical degree, you also must achieve certain level of certifications. Here in the US there are some particular type of engineers for which the title is regulated, for example civil engineer. The IEEE says: The title, Engineer, and its derivatives should be reserved for those individuals whose education and experience qualify them to practice in a manner that protects public safety. Strict use of the title serves the interest of both the IEEE-USA and the public by providing a recognized designation by which those qualified to practice engineering may be identified. The education and experience needed for the title, Engineer, is evidenced by - Graduation with an Engineering degree from an ABET/EAC accredited program of engineering (or equivalent*), coupled with sufficient experience in the field in which the term, Engineer, is used; and/or - Licensure by any jurisdiction as a Professional Engineer. - A degree from a foreign institution (or the total education when one person holds a graduate degree in engineering but no accredited B.S. in engineering) can be evaluated through a service offered by ABET. Not sure if there similar regulations that apply in Canada. Cheers Jorge, This is pretty much what I was after. Thanks for digging it up for me. Steve
Re: Finding content in your job title
On 2010.03.30 23:47, Jorge Amodio wrote: that's right Steve, as I said before, what you do and how you do it, and in particular what do you contribute to the networking community will speak much better of yourself than any title you can imagine. Do you think that folks like Tim Berners-Lee, Vint Cerf, Jon Postel, etc, etc, need a title ? Focus on the substance not on the appearance. grazie, I capire. My post was two fold... and I received a *lot* of off-list feedback that I'll have to respond to tomorrow. Generally, I know that a title isn't relevant, especially in the small little area that I'm in. I was just very curious, as it came up in discussion today. I like to think that I do everything possible to do my part. To be honest, I have as much or more interest in protecting other ASs than I do our own clients (shhh ;) Thanks very much Jorge. Although this was a fast-paced thread that was very entertaining, you've enlightened me. Cheers, Steve -- new sig - stevieb - senior master of disaster - wrongly null-routing client bgp communities, and allowing x-vlan sniffing since 1998
Re: Finding content in your job title
On 2010.03.30 23:50, Anton Kapela wrote: On Mar 30, 2010, at 11:34 PM, Jorge Amodio wrote: The title, Engineer, and its derivatives should be reserved for those individuals whose education and experience qualify them to practice in a manner that protects public safety. Strict use of the title serves ...fortunately for us (and CCIE's around the globe) running the Internet doesn't involve much public trust. Does it? In a few states in the US, working for the same engineering firm for some number of years (usually 6 or more) counts similarly as passing a state-administered professional engineering exam. It would be with some significant precedent, then, that a job or other professional experience does indeed equate to state-sponsored public trust. So, back to Steve's first question: How does the ops community feel about using this designation? If you've been doing it for a while, and not been chased out, I would argue there is ample precedent to support don'ing the title. I guess the sticky-bits here include, potentially, a derth of colleges and graduate study calling itself network engineering. Failing that, perhaps nanog-l could take a vote: Does Steve deserve the title of Network Train Driver, list? Not acceptable. I do not want this. I read and review messages and documents from people who have *much* more experience than I do every single day, and whom I respect to the n'th degree. This isn't a vote count. I am _not_ an engineer, and do not need or desire the title. Thanks anyway though ;) Steve
Re: Posting from freebie E-mail Accounts
On 2010.03.30 23:42, Andrew D Kirch wrote: I am proposing that the NANOG administration drop everything originating from commonly used webmail providers, I oppose this proposal. There are very legitimate (and legal) reasons why people may want to post to an operational list, using an address that can not tie them to the location or business that they are posting from. This list does not see much spam (or at least I don't). That said, let the list maintainers decide. Steve
Re: IPv6, multihoming, and customer allocations
On 2010.03.16 17:01, Joel Jaeggli wrote: On 03/16/2010 07:38 AM, Rick Ernst wrote: Regurgitating the original e-mail for context and follow-up. General responses (some that didn't make it to the list): - There really is that much space, don't worry about it. - /48s for those that ask for it is fine, ARIN won't ask unless it's a bigger assignment - /52 (or /56) on smaller assignments for conservation if it makes you feel better - Open question on whether byte/octet-boundary assignment (/56 vs /52) is better for some reason I haven't seen anything on the general feel for prefix filtering. I've seen discussions from /48 down to /54. Any feel for what the standard (widely deployed) IPv6 prefix filter size will be? I filter at /48. Although I'm small and insignificant, I do too. I would consider filtering on something shorter for assignments of /32 or shorter if there were obvious bad behaver's. We do advertise more specific /36s but we also have the covering /32. I think that it's going to filter down into a situation where people who can allow a prefix might change their policy, given that the originator is known. That doesn't mean that the next person in the chain will accept it though. For me, I'll accept /48's until one of two things happen: - the RIRs decide that they won't be handing them out anymore - that my routers can't handle the number of prefixes Other than that, I'd like to see /48 become a standard for acceptance. Steve
Re: IPv6, multihoming, and customer allocations
On 2010.03.16 21:06, Steve Bertrand wrote: On 2010.03.16 17:01, Joel Jaeggli wrote: On 03/16/2010 07:38 AM, Rick Ernst wrote: Regurgitating the original e-mail for context and follow-up. General responses (some that didn't make it to the list): - There really is that much space, don't worry about it. - /48s for those that ask for it is fine, ARIN won't ask unless it's a bigger assignment - /52 (or /56) on smaller assignments for conservation if it makes you feel better - Open question on whether byte/octet-boundary assignment (/56 vs /52) is better for some reason I haven't seen anything on the general feel for prefix filtering. I've seen discussions from /48 down to /54. Any feel for what the standard (widely deployed) IPv6 prefix filter size will be? I filter at /48. Although I'm small and insignificant, I do too. I would consider filtering on something shorter for assignments of /32 or shorter if there were obvious bad behaver's. We do advertise more specific /36s but we also have the covering /32. I think that it's going to filter down into a situation where people who can allow a prefix might change their policy, given that the originator is known. That doesn't mean that the next person in the chain will accept it though. For me, I'll accept /48's until one of two things happen: - the RIRs decide that they won't be handing them out anymore - that my routers can't handle the number of prefixes Other than that, I'd like to see /48 become a standard for acceptance. err... if the /48 was allocated/assigned from your local RIR from a block that was originally designed for such purposes. Otherwise, I don't blame anyone who is selective on filtering above /48 when the original alloc was /32 (or larger). Steve
Re: IP4 Space
On 2010.03.04 20:55, Owen DeLong wrote: Folks, I know that IPv4 is down to bread crumbs. That's why I'm ready for IPv6 and hopefully the rest of you are or will be soon. However, let's consider how much address space is saved by going from /30 to /31 on every point-to-point link in the internet... Let's assume that there are ~1 million routers on the internet with an average of 8 point to point interfaces. (I think there are probably more like 1/4 million and the average is probably more like 2, but, absent real numbers, I'll be uber-conservative). 8 million /30s is 32 million IPs, or, 2 /8s world-wide. 8 million /31s is 16 million IPs, or, 1 /8 world-wide. We burn roughly 14 /8s per year in new allocations and assignments. So, assuming: 1. There are actually 8 million point to point links in the internet 2. All of them are currently /30s 3. Absolutely optimum use of addresses for all those links 4. All of them are converted to /31s (none of these assumptions is likely in fact) The most we could achieve would be to extend IPv4 freepool lifespan by roughly 26 days. Given the amount of effort sqeezing useful addresses out of such a conversion would require, I proffer that such effort is better spent moving towards IPv6 dual stack on your networks. Owen, thanks for this picturesque description. Whoever recommended the FAQ, add this equation into it. I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;) Nice. Steve ps. and I'm just tiny. I just enjoy seeing reports of the big boys moving forward, and watching my v6 routing table grow...
Re: IP4 Space
On 2010.03.04 16:53, William Herrin wrote: On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber s...@academ.com wrote: On Mar 4, 2010, at 1:30 PM, William Herrin wrote: Because we expect far fewer end users to multihome tomorrow than do today? I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows. Alrighty then... heh. Stan, you've got things backwards, no matter which direction you are looking at things from. I'm thinking that you may have written the sentence incorrectly. It's unfortunate, but it is reality. Have you reviewed your RIR policy lately? v6 will be flying out the window soon, and your local RIR may be assigning PI space like candy. Welcome IPv6. Steve
Re: IP4 Space
On 2010.03.04 22:26, Steve Bertrand wrote: On 2010.03.04 16:53, William Herrin wrote: On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber s...@academ.com wrote: On Mar 4, 2010, at 1:30 PM, William Herrin wrote: Because we expect far fewer end users to multihome tomorrow than do today? I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows. Alrighty then... heh. Stan, you've got things backwards, no matter which direction you are looking at things from. I'm thinking that you may have written the sentence incorrectly. It's unfortunate, but it is reality. Have you reviewed your RIR policy lately? v6 will be flying out the window soon, and your local RIR may be assigning PI space like candy. Welcome IPv6. fwiw, it didn't appear clear to me that my own comments reflected my feelings that the migration was a good thing ;) STeve
Location of upstream connections BGP templates
Hey all, I've got a couple of questions that I'd like operational feedback about. . Although we're an ISP, we currently are only an access provider. We don't yet provide any transit services, but the requirement for us to do so may creep up on a very small scale shortly. Nonetheless... I'm on the latter stages of transforming our network from flat to layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I can eliminate ACL/filtering etc from the core, and push it ALL out toward the edge, keeping the core as fast, sleek and maintenance-free as possible. I visualize my transit providers as essentially 'access', not part of my core backbone. What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but I can't see how that makes sense for any provider that provides (mostly) access services. I'm looking for feedback from both large and small providers, just to gain some perspective. Another question, along the same lines, due to recent discussions, I've done a great deal of research on BGP templates, and now want to migrate to them from peer-group. Before I waste lab time configuring things, I just want to ask for feedback based on experience on whether the following makes sense/will work for transition: - configure template structure - 'no' a single neighbour - apply templates to neighbour - the neighbour comes back up - wash, rinse, repeat Steve
Re: Location of upstream connections BGP templates
On 2010.02.17 19:38, Scott Weeks wrote: --- st...@ibctech.ca wrote: layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but Border, core, access. Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else. This was my thought. However... no fat-finger accidents using Team Cymru in conjunction with my internal RTBH triggers with uRPF enabled on every single 'edge' interface ;) This was the basis of my original question. I want to keep this setup at edge-only, and don't want to have to apply it within the core gear. Core is for moving bits as efficiently as possible: no acls; no filters. ...which is what I visualize, and essentially want. Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-) I guess I see 'border' and 'access' as the same. Fat-fingering is important to me. My pref-list is created long before I turn up a BGP session to a client, and the peering is tested internally before I allow them to advertise anything (or I advertise anything to them). At this point, I only have one _true_ peer that advertises their space directly to me, and it is tied down to the last bit. I even informed them that I will perform max path, so they will drop if they break it. Not scalable for multiple clients, but I've learnt a lot. I need to learn now how to scale, which is why the second half of my question dealt with templates. One template, less chance for me to fat-finger :) Cheers, STeve
Re: Location of upstream connections BGP templates
On 2010.02.17 19:41, jim deleskie wrote: Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more. Hi Jim, Unfortunately, I have a mix of EOL Cisco gear in my network, along with other random custom-built software routers, HP Procurve switches etc. To be honest, I am very pleased with what I've learnt over the course of the last two years with my network re-design/build. In my environment, the layered approach is working exceptionally well (and my sales skills would have me recommend a different ISP at the drop of a dime if they could provide what I couldn't ;) Primarily, my transition has led me down the BCP 38 path (and it's associated techniques/side-effects, specifically automated S/RTBH), which aside from IPv6, is the most important thing I believe that I could have accomplished during that time. It would, however, be interesting to learn how the former drawbacks of flat networks have evolved, and what new technologies make them successful once again. Thanks, Steve
Re: Location of upstream connections BGP templates
On 2010.02.17 20:19, Jared Mauch wrote: On Feb 17, 2010, at 7:10 PM, Steve Bertrand wrote: Hey all, I've got a couple of questions that I'd like operational feedback about. . Although we're an ISP, we currently are only an access provider. We don't yet provide any transit services, but the requirement for us to do so may creep up on a very small scale shortly. Nonetheless... I'm on the latter stages of transforming our network from flat to layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I can eliminate ACL/filtering etc from the core, and push it ALL out toward the edge, keeping the core as fast, sleek and maintenance-free as possible. I visualize my transit providers as essentially 'access', not part of my core backbone. One of the challenges is how do you decide if something is core vs access. If both are the same speed, is there a reason to keep them on different devices? Hi Jared, They are not at the same speed. Typically, the majority of the 'access' or 'edge' is 100Mb, whereas the 'core' consists of 1Gb up to four 1Gb agg links. How do you aggregate your customers if they are the same speed as your core? They are not. For instance, I have an SDSL network where max theoretical speeds for each connection is 2048Kb. I consolidate all of these modems/banks into Cat 2900 switches (or equivalent), which terminate into a 2691 (or equivalent) router. The 2961 routers connect directly to two core routers, providing redundancy across the network. Most of these SDSL clients also have a fibre feed out of our same building, advertising address space assigned by us back to us via BGP, with the SDSL as backup-only. The fibre links are 100Mb each. The fibre from the clients terminate within a building down the street, and we have 10 such clients on a pair of fibre. Each pair of fibre run across Gig transceivers to our building. Each client is within it's own vlan, 10 vlans connect to 10 sub-ints on a router from the switch. This 'access' router then is LACP (generally 2gi) to each 'core'. The 'cores' have multi-gig feeds into the 'access' areas that we host. Each 'access' router (or edge as I refer to it as) protects my network with uRPF etc etc. Are there points of savings? I don't know. Keeping all filtering at the edge saves me much time and much effort. BGP templates will also help. The question is, has it helped...yes, it has, tremendously. Flat or layered, it doesn't take me long anymore to identify points of congestion. The project also has helped me identify what I need to express to my large upstream engineers whenever I come under a direct DDoS, as to save *them* time. I don't know if you're doing T1 aggregation or 10GE, so this is hard to speculate, but I honestly would not spend a lot of time talking to people that have different buckets for a device class. What is core today is always edge in the future. peering edge customer edge core Mean different things to different networks/people. Some see value, others see excess. Agreed. I figured that. I can easily see now that edges are different whether you are a transit provider, access provider etc... Another question, along the same lines, due to recent discussions, I've done a great deal of research on BGP templates, and now want to migrate to them from peer-group. Before I waste lab time configuring things, I just want to ask for feedback based on experience on whether the following makes sense/will work for transition: - configure template structure - 'no' a single neighbour - apply templates to neighbour - the neighbour comes back up - wash, rinse, repeat I've done some examples of templates/community based route filtering here: http://puck.nether.net/bgp/ The examples for Cisco and Juniper should help you create a policy that is sane for your network, or at least something to keep you from leaking transit-learned routes to another one of your transits. (This is very common). Yeah, I know it's common. I can't stand seeing my filtering system sinking/holing BOGON, or more specifically my own IP space that is coming back to me. I'm all for being a good net citizen, and am willing to do whatever it takes to ensure that. I guess my question should have been whether I should move my transit providers to the perimeter instead :) Thanks Jared for the feedback, and the link to the templates. Steve
Re: Location of upstream connections BGP templates
On 2010.02.17 20:45, jim deleskie wrote: Of course all designs are limited to the budget you have to build the network :) Heh, yeah, but it's unbelievable what one can learn on an eBay diet when they put their entire heart, soul and dedication into it! Steve
Re: Location of upstream connections BGP templates
On 2010.02.17 20:48, jim deleskie wrote: Absolutely. I've worked on networks where I'm was amazed on someday we held it all together, but that is truly when you learn the most. I'm very, very happy that there are people out there who can actually see that... Steve
Re: Linux Router distro's with dual stack capability
Jack Carrozzo wrote: Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See the freebsd-isp list. Raises hand. I do, on these boxes: http://www.mikrotikrouter.net/ Steve
Re: CYMRU Bogon Peering
Thomas Magill wrote: In efforts to further protect us against threats I am considering establishing Bogon peers to enable me to filter unallocated address space. I am just wondering if this is a worthwhile step to take and if anyone has ran into any issues or points of concern that I may want to take into account. Thanks in advance for any input. I've used the service for a couple of years, and I find it works wonderfully. Newly distributed IANA blocks are removed promptly, so no need to worry about that. I peer with Cymru on my RTBH trigger boxes, which then redistribute the list to all edge gear which blackholes it (dest and source) thanks to uRPF. No manual config or rule manipulation. Steve
Re: BIRD vs Quagga
Fried, Jason (US - Hattiesburg) wrote: I was wondering what kind of experience the nanog userbase has had with these two packages. Quagga++. I've never tried the other. I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of trickery, it fits in nicely with my RANCID setup, and what I like best is that it (mostly) follows Cisco's command convention. There are also very active developer and user mailing lists. For the most part, I wouldn't know if I was writing a config for a Cisco or for a Quagga box. fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. Steve
Re: CYMRU Bogon Peering
Seth Mattinen wrote: On 2/12/2010 13:47, Tim Wilde wrote: On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote: I've a question for the CYMRU Team , My reasoning for posting here is to get a much wide knowledge base . Does or Is the 'Bogon Peering' Product(?) , Only at the IANA-RIR allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE . Or Does the product also include the actual remaining non-allocated space at the RIR-EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 to anubusstupidity, inc. Jim All, The current bogon reference projects we have available only include the first of your examples - netblocks which have not been allocated by IANA to an RIR. However, we are currently in a beta testing phase of a similar feed which also includes netblocks that have not yet been allocated or assigned by the RIRs. We will also be offering the same type of bogon feed for IPv6, something we've been asked about quite a bit recently! While I have your attention, I've noticed there's been a bit of instability lately with the BGP sessions (in fact one of mine right now is down). With 30 routes it's not a big deal to have frequent churn, but if you're going to expand that to a larger feed then it could become a problem. What time frame do you determine to be instability? The following is from a box that has ~25 neighbours. Since the box was reloaded (6w3d ago), I've had the same uptime with the Team Cymru neighbours as I do with internal gear. I can't say that I've experienced any instability at all. It is not uncommon for me to have noticed uptimes well beyond 30w. trig-2#sh ip bgp sum NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 68.22.187.244 65333 81750 65849 6700 6w3d 30 216.165.129.196 4 65333 81748 65849 6700 6w3d 30 trig-2#sh ip bgp nei 68.22.187.24 Prefix activity: Prefixes Current: 0 30 (Consumes 1560 bytes) Prefixes Total: 0 36 Implicit Withdraw: 0 0 Explicit Withdraw: 0 6 ...snip... Connections established 1; dropped 0 Last reset never Steve
Re: dns interceptors
Jared Mauch wrote: On Feb 12, 2010, at 5:15 PM, Randy Bush wrote: i just lost ten minutes debugging what i thought was a server problem which turned out to be a dns trapper on the wireless in the changi sats lounge. this is not the first time i have been caught by this. what are other roaming folk doing about this? randy I typically VPN out of broken networks whenever possible. Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around the issues. Yep... On Windows laptop, a wrapper .bat sets up Putty (SSH) to configure a tunnel to a remote server, and for FBSD, an sh script with the SSH command line within. Depending on the situation, the tunnel may handle all core protocols, even 587 when it has been hijacked/blocked. Steve
Re: dns interceptors
Jim Richardson wrote: On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush ra...@psg.com wrote: i just lost ten minutes debugging what i thought was a server problem which turned out to be a dns trapper on the wireless in the changi sats lounge. this is not the first time i have been caught by this. what are other roaming folk doing about this? randy ssh tunnels to IP address I sent this directly to Randy, but perhaps there are others who are interested in doing this as well. For the archives (and my own documentation): My DNS server doesn't listen on localhost (a prereq), so I'll use submit port instead: # on the roaming laptop (hereinafter 'client') # -f == run in background # st...@host is the submit server # -L means map this port 587: to remote-host:port # -N means do not execute remote command client# ssh -f st...@208.70.104.210 -L 587:208.70.104.210:587 -N ...now I tell my local resolver (or in this case, my MUA) to use localhost instead of the normal remote host. Note that I generally use the standard ports on my localhost for this mapping. Doing so will not work for things like HTTP etc, as we are focused squarely on accessing resources located on our own equipment... ...SSH tunnelling even works over v6. The colon-separated address isn't handled well within the port-mapping portion of the command, so we'll use names instead: pearl# dig smtp.ibctech.ca smtp.ibctech.ca.3598IN 2607:f118::b6 ... client# ssh -6 -f st...@smtp.ibctech.ca -L 587:smtp.ibctech.ca:587 -N server# tcpdump -n -i lo0 port 587 client# telnet ::1 587 Trying ::1... Connected to localhost. Escape character is '^]'. 220 smtp.ibctech.ca ESMTP server# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 19:01:20.529444 IP6 2607:f118::b6.59842 2607:f118::b6.587: S 4152936854:4152936854(0) win 65535 mss 1440,nop,wscale 3,sackOK,timestamp 3135691171 0 19:01:20.529497 IP6 2607:f118::b6.587 2607:f118::b6.59842: S 3425118408:3425118408(0) ack 4152936855 win 65535 mss 1440,nop,wscale 3,sackOK,timestamp 322067125 3135691171 19:01:20.529532 IP6 2607:f118::b6.59842 2607:f118::b6.587: . ack 1 win 8211 nop,nop,timestamp 3135691171 322067125 19:01:20.535727 IP6 2607:f118::b6.587 2607:f118::b6.59842: P 1:28(27) ack 1 win 8211 nop,nop,timestamp 322067131 3135691171 19:01:20.635335 IP6 2607:f118::b6.59842 2607:f118::b6.587: . ack 28 win 8211 nop,nop,timestamp 3135691277 322067131 ...I love easy workarounds. I got sick and tired of fscking around a long time ago with troubleshooting blocked/hijacked ports, so I thought I'd bypass the problem by hijacking and re-routing the ports myself. Port tunnelling like this is my default whenever I'm not at home. Even on Windows its easy...all my apps are portable. Steve
Re: CYMRU Bogon Peering
Seth Mattinen wrote: On 2/12/2010 15:03, Steve Bertrand wrote: What time frame do you determine to be instability? The following is from a box that has ~25 neighbours. Since the box was reloaded (6w3d ago), I've had the same uptime with the Team Cymru neighbours as I do with internal gear. I can't say that I've experienced any instability at all. It is not uncommon for me to have noticed uptimes well beyond 30w. Mine are not so good: NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 38.229.0.5 4 65333 115856 115859 1641181400 01:33:51 30 68.22.187.24465333 26968 29671 1631129300 2w4d 30 I see you have 68.22.187.24 in your list too, but my uptime is less. Are you using increased hold times? No... I haven't changed anything. Here is my exact config from said box (for that host): router bgp 14270 !...snip... neighbor cymru-bogon peer-group neighbor cymru-bogon description Cymru BOGON peer group neighbor cymru-bogon ebgp-multihop 255 neighbor cymru-bogon update-source Loopback99 !...snip... neighbor 68.22.187.24 remote-as 65333 neighbor 68.22.187.24 peer-group cymru-bogon neighbor 68.22.187.24 description Cymru route-server #2 !...snip... address-family ipv4 redistribute static route-map RTBH-OUT neighbor cymru-bogon prefix-list CYMRU-OUT out neighbor cymru-bogon route-map CYMRU-MAP-IN in neighbor cymru-bogon maximum-prefix 200 !...snip... neighbor 68.22.187.24 activate !...snip... ip community-list expanded BOGON permit 65333:888 ip community-list expanded BLACKHOLE permit 14270:600 ip as-path access-list 10 permit ^65333* !...snip... ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32 !...snip... route-map CYMRU-MAP-IN permit 10 description Null route BOGONS learnt from Cymru match community BOGON set community 14270:888 no-export additive set ip next-hop 192.0.2.2 !...snip... route-map RTBH-OUT permit 10 match tag 600 set local-preference 500 set origin igp set community 14270:600 no-export !__END__ Do you have any other peers on the same int that are dropping as well? Steve
Re: Cymru Bogon Route Help
Chris Gotstein wrote: I'm in the process of trying to setup bgp peering with Cymru to receive the bogon route list. I've got everything setup using the examples they have listed, but can't get the filtering to actually work on the incoming bgp. Using a Cisco 7200 router. Any off-list help would be appreciated. Email me off-list, and I'll see if I can help you through your issues via telephone. Steve
Re: Using /126 for IPv6 router links
Igor Gashinsky wrote: On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: Matt meant reserve/assign a /64 for each PtP link, but only configure the :: first */127* of the link, as that's the only way to fully mitigate the :: scanning-type attacks (with a /126, there is still the possibility of :: ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: :: Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. If this is the case, why not just use /64s from the beginning? Why bother with hacking it up if it's only going to be reserved anyway? I'm trying to understand how reserving-and-hacking a /64 makes administration any easier. Even if all ptp are coming out of a single /64 (as opposed to reserving a /64 for each), what benefits are there to that? It seems as though that this is v4 thinking. As someone pointed out off-list (I hope you don't mind): one could argue a bunch of sequential /127s makes it apparent what your infrastructure addresses are. You can just as easily ACL a /48 containing infrastructure /64s as you can ACL a /64 containing infrastructure /127s. ...amen to that, if I can't figure out a way to sink/drop the null addresses first. Steve
Re: Enhancing automation with network growth
Steve Bertrand wrote: Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). By popular request, a list of the most suggested software packages. Some were more related to network management in general as opposed to traffic graphic, but - netdisco which I've already got up and running. Although I've only added a few of our devices so far, I can see already how this will be an extremely valuable multi-purpose tool - rancid which I've been using for quite some time already for config management - cacti which I'm strongly considering installing/testing - opennms which appears that it will duplicate many functions I already have deployed on the network (and that I'm happy with), but I may give it a try anyway. If I don't use it, I've got a few 'on the side' clients that could benefit from this all-inclusive package - snmpstat which I may install and test, if only to look at a replacement for my custom BGP peering alerting system - MRTG, with a custom cfgmaker. This was my original idea. If those who recommended this could/are allowed to share their code, please let me know - netflow v9 the majority of my devices don't support this (unfortunately) - bandwidthd already in use for protocol based statistics. This doesn't run full-time in our network, I usually only drop it into place on a span port if I see sustained extreme increases of traffic on a link - IPPlan been using it for a few years Some software supports IPv6, others don't (or have limited capability). Polling IPv6 accounting isn't possible via SNMP, so using scripts with SSH/Telnet access is the only way around that problem for a lot of gear. Cheers, and thanks! Steve
Re: Using /126 for IPv6 router links
Igor Gashinsky wrote: On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... As always, I'm looking for better ways to do things. I've been using /64 eui-64 on P-PE PtP Ethernet links (and /64 static on PE-CE) since I first delved into IPv6, as (for me) it makes hardware replacement/link relocation very easy, and documentation simple. ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. I don't think I'm quite grasping the entire security concern here. Actually, I'd like to re-word that... I do grasp the attack vector to a certain degree, but there *must* be a way to use entire /64's on ptp links without having to use manual ACL management. Personally, I am all for using /64s for this purpose, as that's how I understand the intention of the protocol. Whether I use a complete /64 within a ptp (particularly Ethernet), or lob off a /127 (or /126) for the purpose, I'll always keep that entire /64 'specifically reserved for that purpose' either way. Would be interesting to hear ideas on how this particular /64 on ptp attack vector could be nullified by using existing known solutions. I'm thinking blackhole, but can't (at this time) think how that could be done by default with existing configuration within the scope of a ptp link. Steve
Re: Enhancing automation with network growth
I want to thank everyone who responded on, and off-list to this thread. I've garnered valuable information that ranges within the technical, business applicability, to 'common-sense' arenas. There is a lot of information that I have to go over now, and a few select pieces of software that I'm going to test immediately. One more question, if I may... My original post was completely concerned on automating the process of spinning traffic throughput graphs. Are there any software packages that stand out that have the ability to differentiate throughput between v4/v6, as opposed to the aggregate of the interface? (I will continue reading docs of all recommendations, but this may expedite the process a bit). Steve
Re: 2009 Worldwide Infrastructure Security Report available for download.
Pekka Savola wrote: On Wed, 20 Jan 2010, Stefan Fouant wrote: Completely agree on the disturbing observation of the increase in rate-limiting as a primary mitigation mechanism for dealing with DDoS. I've seen more and more people using this as a mitigation strategy, against my advice. For anyone interested in more information on the topic, and why rate-limiting is akin to cutting your foot off, I highly recommend you take a look at the paper Effectiveness of Rate-Limiting in Mitigating Flooding DoS Attacks presented by Jarmo Molsa at the Third IASTED International conference. Thanks to Arbor for collecting the report and your observations. Indeed. One thing I found extremely strange is that almost 50% report they use BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer direction. (Figure 13, p20) I wonder if peering edge refers to drop your own addresses or real strict uRPF (or the like)? Depends. It can do that, BOGON, and any other prefix you want your edge to discard. I would imagine that it would be difficult to use strict uRPF on a peering interface though, as packets through that peer may be received on a different interface than it was sent on (in a multi-homing situation). I do strict uRPF for any directly connected clients (SDSL, fibre, collocation etc) that are single-homed. It's literally one command on a router interface that is connected to the switch (subnet) of aggregated clients. For our clients that multi-home into two of our different edge gear via BGP, I use loose uRPF. This allows fail-over without packets being dropped. In some multi-homed client cases, I can get away with using strict. This is possible in situations where a client has one high-bandwidth link and one low-bandwidth link in a fail-over-only case. If BGP is set up correctly, the secondary link will never be used until the primary goes down. All packets are sent/received on the only interface in the network that knows about the client prefix, so it works. If the primary fails, the secondary takes over completely, so again, strict works. Loose uRPF allows a packet to come into any valid interface (and you can even allow default route). This seems counter-intuitive, however, the important point to note is that once uRPF is enabled even in loose mode, it will effectively allow you to drop based on source address when combined with RTBH on any interface it is configured on. If not I'm curious if this is for real, and how in earth they're doing it, especially given that in Fig 15 (p22) shows they don't implement BGP prefix filtering. If you can't filter BGP, how could you filter packets? Based on my experience, even if you filter BGP, you may not be able to filter packets except in simple scenarios. This isn't about packet 'filtering', it's about 'dropping' (or sinking). Essentially, in a uRPF [S/]RTBH setup, your edge routers are configured with routes that point to a special address that is destined (eventually) to null (usually this is automated...the routes are sent to the edge via a 'trigger' box). When a packet comes in (or attempts to go out) of the interface configured with uRPF, the system treats the null route as best-path, and discards (or forwards) it. This setup does not require you to have ANY eBGP whatsoever, and also works in deployments where all of your eBGP peers are sending only default. As long as you have iBGP to all edge devices, this setup is pretty trivial to configure. Throw in a Team Cymru route-server peering on your trigger box, and you've automated BOGON management network-wide. I don't think I explained this very clearly (hopefully it was accurate... it is early in the morning ;). Here is a decent 'howto': http://www.packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/ Steve
Enhancing automation with network growth
Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSDQuagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve
Re: d000::/8 from AS28716
Mark Jackson wrote: I'd say that is a bogus route/AS announcement. I see nothing in the address assignment for that. But I see traffic started originating around 12/15/2009. I envision that work will be done in this regard shortly. God willing, our RIRs will be handing out prefixes to everyone from blocks that are specifically designed for 'that purpose'. It's interesting to know that since we are so virgin v6, that the RIRs should have no problem shelving up address space into an easy-to-document format. Although the RIRs can't dictate routing policy, routing/ops people can dictate what the RIR policy states. Then, Team Cymru will have an easy time laying base with an 'allowed' as opposed to a 'denied' list of addresses. Steve
Re: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)
Michael Sokolov wrote: Frank Bulk - iName.com frnk...@iname.com wrote: We offer it, but practically speaking we haven't gotten much higher than 1.5 Mbps on the upstream. Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? I have spent the past 5 years of my life learning everything there is to know about SDSL. Don't ask me why, I don't really know the answer to that question myself. I won't waste the bandwidth of this elite list with dirty details of just what I've done with SDSL over the past 5 y, but I'll give a link to an open source project that contains the body of SDSL knowledge amassed over those years: Michael, I'm but a small humble ISP. We have sold SDSL since ~1996. The bonded circuits have been terminated differently over the years, but I still have a fair number of business clients that have SP supplied CPE that is extremely affordable, and that require little to no work on our part. Other than a few stragglers that I keep afloat on SDSL that require fail-over, I've been trying to get rid of the dedicated copper as much as possible, since I 'lease' the copper for the dry circuit(s). We've reached past the break-even point for fibre access within our area, and am at the point where the *very* 'ritzy' resi clients can and will soon be approached. The max length of SDSL that I currently have is 6.7 wired km. Bonded, our longest distance is 5.4 km. Peak throughput over our longest bonded (2 pair) SDSL circuit is 2.25Mb. Given relative average, in the locations that I can provide optics, there is a gain of revenue percentage that I achieve over standard copper SDSL. IOW, when revenue for a bonded SDSL circuit is $285 and I pay $49.40 per circuit for the four wire copper, things begin to look more attractive when I pay *nothing* for the dark fibre, but am able to provide multiple times the bandwidth at the same price to the client ;) fwiw, for bonded SDSL, we have currently: - Symmetric GoWide units deployed (both on the PE and CPE) that inherently manage two-pair which requires but one switch port and no configuration. Aggregates internally. - an 'Elastic' rack that requires a bit more setup on both ends. Terminate into a vlan on a switch to aggregate properly. A 'setup' fee covers this one-time fix. Remember, small ISP, I'm not used to scaling human resources ;) - multiple other stand-alone SDSL modem types (dslam/non-dslam, such as PairGain etc) - Copper Mountain BTW, while on topic, if you know anyone who wants a fully shelved and carded Copper Mountain CE200 dslam w/ dual power supplies, let me know ;) Steve
Re: D/DoS mitigation hardware/software needed.
Adrian Chadd wrote: On Tue, Jan 05, 2010, Dobbins, Roland wrote: None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions. But as you said, they're willing to sell them to you. Then claim that the traffic you're receiving is out of profile. :) (I'm not jaded about this, oh no..) ...so, out of curiosity, which one did you buy? ;) Steve
Re: Bonded SDSL
sth...@nethelp.no wrote: Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? Not only is there interest, it is actually seeing significant use - at least here in Norway. Typical case is bonding 2 or 4 SHDSL links for a total capacity of 4 or 8 Mbps. Out of curiosity, in Norway, who owns the copper? What is your revenue/lease cost ratio? off-list if too far off topic. I'm just curious. I'm about the Toronto Canada area, and I'm just looking at the rough lease cost per km. Be interesting to see if the same figure shows up elsewhere, or, for all I know, perhaps not all countries have a single 'owner' of the copper... Steve
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
Wade Peacock wrote: We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. For ADSL, we've been punting Ovislink gear for a few years. In the past, I've had very good results with having feature requests implemented by the firmware developers (sometimes while I'm on the phone with them, literally). I haven't pushed the v6 thing too hard yet, as our DSL is wholesale'd out, and the wholesaler(s), unlike myself, don't do IPv6. I will gladly rekindle the relationship with the Ovislink dev contacts regarding IPv6, as I'm sure they will respond if there is a show of potential hardware sales to a few ISPs larger than I am. Steve
Re: BGP Peer Selection Considerations
a...@baklawasecrets.com wrote: Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B ...I've likely missed something, but get the IP/ASN for yourself. *ensure* that A B will peer and provide transit for you. (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. ...until you find out that the backhaul network is owned by Provider B, or virtualized within an existing circuit to someplace else. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. But at what cost? Am I missing things that I need to consider? I think so. Long-term survival for one. If you are budgeted for a diverse and redundant network, then I recommend that you ensure one. My current understanding is that you can negotiate terms with potential providers where there is competition. Don't allow any of your ISPs to manage/dictate the use of your address space. It will bite you, and cause undue frustration. Steve
Re: Upstream BGP community support
Andy B. wrote: Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Without reading any more of your post, or any of the replies: - because leadership has a better bandwidth deal - cuz even though shit in one hand is heavier than hope in the other, you can't convince anyone What sucks: - having to deal with transit from someone who performs no filtering whatsoever - dealing with transit who DOESN'T RESPOND TO REQUESTS FOR BGP PEERING - dealing with transits who don't know what v6 is, or won't respond to requests (at all), even though the network who is purchasing their transport has better v6 redundancy than v4. I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Steve
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) Well, send it over... I'd like to see a copy of Here's why ...first. Steve
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) ...and directly to your statement: send the book along. I'm not looking for a 'peer'. This is a situation that my PROVIDER won't set up a BGP SESSION with me, and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. They advertise it from their AS. Their AS advertises known bad space to me (which I've complained about). Their AS, In my humble opinion, is completely unreliable and non-trustworthy. My ARIN block is advertised by them, and I HATE it. They will not respond to me when I ask them to allow me to advertise my own space to them. Of course, having them 'listen' for my space, it would also allow me to advertise to other 'providers' which would allow for redundancy Note...I have a /21. It's not like I'm advertising a /24, nor am I trying to do something that isn't in the best interest of my community. Steve
Small guys with BGP issues
Seems to me that some people have issues when a thread is taken over. capiche... However, it also seems to me that there are people here who are intelligent engineers who are afraid to speak, due to the size of the company they work for. On behalf of the 'small guys', it sucks when you big(ger) guys: - don't listen to us - practice good behaviour (bcp38) and don't preach it - speak proudly of decent support, but don't respond to people who aren't staffed by a tier(x) - act as though you know something, but won't get out of the textbook mentality - again, this isn't a test for ccie, just because were working in smaller *sp's doesn't mean that we know less than you - we work hard. We have smaller networks. I bet we defend our border egress to you than you defend toward us - if all small guys like me are the same, then the 'big boys' should be motivated to move forward Lets take it off topic and off-thread... This is a big-boy list. Out of the small guys on this big boy list, lets have a hands-up for who is doing the right thing (v6 network defence protecting their connected networks )... Steve
Re: Small guys with BGP issues
Steve Bertrand wrote: Seems to me that some people have issues when a thread is taken over. capiche... However, it also seems to me that there are people here who are intelligent engineers who are afraid to speak, due to the size of the company they work for. On behalf of the 'small guys', it sucks when you big(ger) guys: - don't listen to us - practice good behaviour (bcp38) and don't preach it - speak proudly of decent support, but don't respond to people who aren't staffed by a tier(x) - act as though you know something, but won't get out of the textbook mentality - again, this isn't a test for ccie, just because were working in smaller *sp's doesn't mean that we know less than you - we work hard. We have smaller networks. I bet we defend our border egress to you than you defend toward us - if all small guys like me are the same, then the 'big boys' should be motivated to move forward Lets take it off topic and off-thread... This is a big-boy list. Out of the small guys on this big boy list, lets have a hands-up for who is doing the right thing (v6 network defence protecting their connected networks )... Holy shiat, I can't even deal with the off-list feedback! Thank you! Politically, unfortunately, I'm not that type. I can't do much there. I wish that I could make decisions with the company purse, but I can't... On the other hand, I wish I could direct operations. I know what needs to be done, and I know how to command people to get there. I *think* I know how to direct an entire company (given its geo-location) to success given the area it's in. Nonetheless, I am where I am, and I like it. I am responsible for what comes into my network, and what leaves it. I have written an ISP management system, and ensure/troubleshoot montly revenue streams. I love my job. I love being an ISP. Unfortunately, my ISP doesn't love me the same way. ( I can understand the business aspect, but at least show that you are technically inclined!) Steve
Re: Small guys with BGP issues
Patrick W. Gilmore wrote: - practice good behaviour (bcp38) and don't preach it Did you mean preach but don't practice it? While I appreciate everyone who preaches it, I am not going to complain in the slightest at any big guy who practices BCP38. Just the opposite, I'm going to praise them whether they preach it or not. I'm not a political person. Take it for what it is worth. I personally know people who do both: - practice but not preach - preach but don't practice ... however you take my point, I don't care. I just wanted it to be known that the 'guys' who do practice it should 'God willing' come out and preach it. And this is not the big boy list. This is for all Operators in North America, and many who are not, regardless of size. (Well, I guess we'll exclude the guy who buys are cable/DSL link and provides to his mother father with a LinkSys.) eh, -stevieb has much respect for all those who read this list, and when he posts, feels that the big guys are looking down upon him... hopefully with approval. Steve
Re: Small guys with BGP issues
Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: I'm not a political person. Take it for what it is worth. I personally know people who do both: - practice but not preach - preach but don't practice ... however you take my point, I don't care. I just wanted it to be known that the 'guys' who do practice it should 'God willing' come out and preach it. And this is not the big boy list. This is for all Operators in North America, and many who are not, regardless of size. (Well, I guess we'll exclude the guy who buys are cable/DSL link and provides to his mother father with a LinkSys.) eh, -stevieb has much respect for all those who read this list, and when he posts, feels that the big guys are looking down upon him... hopefully with approval. Ok so, without getting into debates over being political, practicing vs preaching, BCP38, or big guys vs little guys, can you please explain in clear english what in the name of holy hell you're talking about? What is the issue here, that your DSL provider won't speak BGP with you no matter how many times you've asked, so you're complaining to NANOG Theoretically, I'm not complaining, I'm venting. This isn't just my DSL provider, its a business class connection provider who also happens to provide my (hrm.. our) primary Internet connection. Are you going to teach me something with a clue bat, or are you going to beat me to death with the specifics that each prong of a fork carries? Please correct me if I'm reading this wrong, but the emails so far haven't been very clear and this isn't making a lot of sense. My apologies if I haven't been clear. What would you like me to say? If I can't 'complain' here, where do I go? I think that I've acted tactfully and responsibly. What didn't make sense? Enlighten me. Although I did come here with concerns and questions, I do have a clue bat of my own to swing in defence... Steve
Re: Upstream BGP community support
jim deleskie wrote: Agree'd :) On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush ra...@psg.com wrote: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. For those who try their best, given your comment, what in the fsck is one to do? What practices should be followed? Is this about not pushing knobs, or is this about people with big dicks? What really should we do? I mean those with 2691's still in practice. What do we do? We watch for guidance from here. It seems as though people are making a mochary of communities. How many steps am I really behind? Steve
Re: Small guys with BGP issues
Richard A Steenbergen wrote: On Mon, Nov 02, 2009 at 12:42:51AM -0500, Steve Bertrand wrote: This isn't just my DSL provider, its a business class connection provider who also happens to provide my (hrm.. our) primary Internet connection. Are you going to teach me something with a clue bat, or are you going to beat me to death with the specifics that each prong of a fork carries? Sure, I'll give it a brief shot... Some Internet connections are simply not designed to support customer BGP. When someone says business class service over cable or DSL, typically what they're talking about is we'll route your calls to a slightly higher class call center, and we'll provide you with 5 e-mail addresses/IPs and 50MB of hosting for your website instead of just the usual 1 email and 1 dynamic IP. The DSL gear may very well not be able to speak BGP to a customer at all. Each provider gets to decide what service they do and don't want to sell, and your provider has clearly decided they don't want to sell you BGP. From the providers' point of view, I'm sure this makes perfect sense. I'd love to get Comcast to speak BGP to my cable modem, but I have absolutely no delusions that they will ever do so. There is more than likely nothing you're going to be able to do about it, and the more you complain about it like this the more likely they are to move you into the this guy is a nut and we don't want your business at all category. Richard, I appreciate your concern. I would have expected however that you might have understood that I wasn't asking about some resi-type connection. Yes, we are small. I would love to be in a position to say that our 100Mb connection qualifies... Regardless... If you don't like the service you're getting, vote with your money and buy from someone else. This is quite simply not a NANOG issue, but in the interests of being helpful the best advice I can give you is this: Your request is unreasonable, and you should adjust your expectations that you'll ever get it from the service you are purchasing. Tell me, what can you offer me? Here are my immediate purchasing qualifications: - 100Mbps - space in Torix - optic, from Toronto, Ontario to Cobourg, Ontario (55 miles) - gear at both ends We pay ~$2500 for the fibre and the bandwidth. Get me a deal. I am not the money man. I don't even want to deal with money. I can't vote with money, as it's not mine. Believe me, if I could vote with money, I'd be 100% HE. I'm venting. I'm allowed to vent here. I think I'm qualified to do so. Even though I can't speak with $, there are those who know my determination to keep a clean network, and they may be willing to help me in the future. Steve
Re: Small guys with BGP issues
Adrian Chadd wrote: On Mon, Nov 02, 2009, Richard A Steenbergen wrote: If you don't like the service you're getting, vote with your money and buy from someone else. This is quite simply not a NANOG issue, but in the interests of being helpful the best advice I can give you is this: Your request is unreasonable, and you should adjust your expectations that you'll ever get it from the service you are purchasing. Sorry if that's not the answer you want. :) Or you could look at alternatives with your provider, ie: Ok, so we can't speak BGP over that particular link. May I colocate some router with you at extra cost and connect to you via -that-, so I may then speak BGP to you over that and then tunnel my data back to me over your DSL network? That way you don't require your ISP to speak BGP over a DSL link and all of the headaches they may not be prepared for, and you get control over your own network. heh, Adrian, unfortunately, it's political, out of my grasp. Thankfully, these threads should be enough to either get things moving forward, or get me fired. Either way, progress was made. I'm sick of sitting still. I want to do more. Steve
Re: ISP port blocking practice
Jon Kibler wrote: Steve Bertrand wrote: Jon Kibler wrote: To answer that question, I would start with ingress and egress filtering by IP address, protocol, etc.: 1) Never allow traffic to egress any subnet unless its source IP address is within that subnet range. Sorry to nit, but shouldn't your uRPF setup take care of this (and many other of your list items), long before ACL? It's absolutely great if you have your list implemented, but imho, all ISP's, no matter how small should investigate and implement urpf. It's especially fun to play with RTBH. To be honest, the smaller you are, the easier it is to implement (ie. urpf strict everywhere! :) Steve Agree for the most part. However: 1) The overwhelming majority of routers I have audited do not have uRPF implemented and most admins do not comprehend it, but they do comprehend (usually) ACLs. Fair enough. However, a considerable portion of my PE and CE gear consists of 2691's in which uRPF is enabled, so I'd have to wonder which hardware doesn't support it. Even my routers running FreeBSD/Quagga have it enabled. Aside from that, I truly did mean kudos for the poster for at least putting in the effort for configuring such an elaborate ACL setup :) As for the admins not comprehending it, imho, if someone is in a position of operating an Internet Provider network, particularly one that utilizes BGP, they need to comprehend it, if even just for the respect of the community. IIRC, it was about two weeks after I read Kumari's initial draft that I had it not only understood, but implemented. Even given the small scale that I am at, it really sucks when you see BOGON/your own prefixes ingress to your network. What's more upsetting, is when you have made more than one request to an upstream to stop it, and you get no response...at all. 2) L3 switching does not always support it, leaving potential for abuse if the network has any donut holes. I didn't think of that angle. My experience with L3 switching is very limited. My understanding is though that most ops use L3 switching closer to the core (as opposed to the edge), where uRPF isn't needed anyhow. 3) uRPF works best on egress but does little on outside ingress (e.g., bogons). Unless you have implemented an automated s/RT(BH|sink). Cymru bogons (learnt via peering) on a trigger box, pushed in through a route-map tagged with the null-route community to the PE. Works magic. 4) Defense in depth dictates using more than one way to detect an attack, so use both ACLs and uRPF. I completely agree. Useful not only as depth, but to patch the holes where one can't implement strict uRPF due to a client having multiple peer-points within your network. Cheers, Steve
