Re: RFC 1149
Subject: Re: RFC 1149 Date: Wed, Apr 03, 2013 at 02:59:47PM -0400 Quoting Jay Ashworth (j...@baylink.com): > George Herbert wrote: > > >In europe? He probably was thinking of a Volvo 245... > > I don't /think/ Andy was over there that far back. "that far back"? The 245 still rolls, and probably will, for another 30 years. /Måns, drove 245 in youth. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The SAME WAVE keeps coming in and COLLAPSING like a rayon MUU-MUU ... signature.asc Description: Digital signature
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 04/03/2013 02:48 PM, valdis.kletni...@vt.edu wrote: On Wed, 03 Apr 2013 14:07:48 -0700, Mike said: These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it. As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream. But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast. (If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...) Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up. These tests are hogwash. Mike-
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
When is speed ever ensured past someone else's edge/border ? You may pass through your upstream that fast but once you are out in the open range you are free game to all the lions, tigers & bears.., There is always going to be something eating you. Best off letting it be the Spanish queasiness from the night before than the results from speedtest.net -- Jason Hellenthal JJH448-ARIN - (2^(N-1)) On Apr 4, 2013, at 4:14, Mike wrote: > On 04/03/2013 02:48 PM, valdis.kletni...@vt.edu wrote: >> On Wed, 03 Apr 2013 14:07:48 -0700, Mike said: >> >>> These speedtests are pure unscientific bs and I'd love to see them >>> called out on the carpet for it. >> >> As far as I know, it's possible for the end-to-end reported values to be >> lower than your immediate upstream due to issues further upstream. >> >> But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is >> able to go *at least* that fast. >> >> (If anybody's got evidence of it reporting more than the link is technically >> capable of, feel free to correct me...) > > > > Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up. > > These tests are hogwash. > > Mike- >
Re: public consultation on root zone KSK rollover
On Apr 4, 2013, at 12:59 AM, Brandon Butterworth wrote: >> The topic at hand and the specific questions that have been >> asked as part of the consultation are important ones; > > Do it when you feel like, nobody should notice. Anything > this important should be routine procedure, make it daily. You do realize this requires changing validating resolver configuration data, right? Regards, -drc
Re: public consultation on root zone KSK rollover
> >> The topic at hand and the specific questions that have been > >> asked as part of the consultation are important ones; > > > > Do it when you feel like, nobody should notice. Anything > > this important should be routine procedure, make it daily. > > You do realize this requires changing validating resolver > configuration data, right? Yes. How hard can it be (answer not required). While it's quaint that the elders of the internet meet and bless each new key I don't think this scales. I know it's not easy but it needs to be simple and automatic for wide deployment. brandon
Re: RFC 1149
> He probably was thinking of a Volvo 245... Duett PV445
Re: route for linx.net in Level3?
oops! i have a host directly on the linx on which i can give you shell access
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
It'd be nice to know if NDT was not accurate as well. Anyone tested it? We've been using it for a few years. On my laptop that runs linux I get fairly consistent results (around 935Mb/s up and down right now) over a 1Gig routed link (a couple routers and a firewall in between.) On the Windows boxes I usually see a 100 to 200 Mb/s drop on the upload side. The last time I checked, you can compile a commandline version of the client. I seem to remember the commandline client not taking quite as bad a hit on the tests compared to running it on linux, but it's been a while since I tried it. For us it's been way more accurate than the various speedtest servers our customers insist on trying. A while back I switched from compiling my own kernel and NDT to using perfSONAR-PS (http://psps.perfsonar.net/). I like that they've got live-cd and net-install versions. If nothing else it's useful for pointing out the difference between a local network issue and Internet Suckage.
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On Thu, 04 Apr 2013 06:18:34 +0200, Mikael Abrahamsson said: > I have pitched the idea in the IETF to have TCP stacks themselves report > IP performance indicators (aggregate) and that a standard for this to be > standardised. No takers so far. RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD) Looks like a taker to me. Also, see the work the Web10G group is doing for Linux: http://www.web10g.org pgpdTw7aMkzcF.pgp Description: PGP signature
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On Thu, 4 Apr 2013, valdis.kletni...@vt.edu wrote: RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD) Looks like a taker to me. Also, see the work the Web10G group is doing for Linux: http://www.web10g.org RFC 4989 doesn't seem to officially exist. Ah, it's 4898. Yes, RFC4898 seems to contain a lot of interesting information, question is how to destill this down to something the user can understand and that is of interest for a support engineer who might be trying to diagnose the customer problem. I agree web10g seems to be of interest as well. I'm going to read through their documents tomorrow. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Speedtest Results speedtest.net vs Mikrotik bandwidth test
The MT speed test is a multi-connection test, think 20 streams or connections at once.Most web based tests are single stream. Now you get into 802.11N speedtests where they are optimized for many connections MIMO operations, hence, a single connection don't show good results, where a MT test at 20 streams would. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace -Original Message- From: Lorell Hathcock [mailto:lor...@hathcock.org] Sent: Monday, April 1, 2013 7:19 PM To: nanog@nanog.org Cc: Nathan Hathcock Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test All: I am having some speedtest results that are difficult to interpret. I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX. I am running BGP with each with 100 Mbps+ on each link. Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results. My network is Mikrotik based and as such, I have access to Mikrotik's built-in bandwidth testing. With a laptop on site, running against speedtest.net (which kicked me over to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5 Mbps down. That is consistent on their desktops too. We eliminated their routing equipment and other consumers of the bandwidth and tested and got similar results. But when we run the Mikrotik bandwidth tests (even to off-net Mikrotik devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous. We have run traceroutes to various traceroute servers and they go through Cogent and/or Level 3. For the most part it does not seem to matter which path it takes, the bandwidth seems to be about the same going both routes. When we run the laptop-based btest.exe against Mikrotik bandwidth test servers, the laptop got significantly better results (14 Mbps) , but not 25+ Mbps. It is almost like there is a Java based problem with speedtest.net. Thoughts? Thanks, Lorell Hathcock
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On Thu, 04 Apr 2013 17:29:40 +0200, Mikael Abrahamsson said: > On Thu, 4 Apr 2013, valdis.kletni...@vt.edu wrote: > > > RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. > > Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED > > STANDARD) > > > > Looks like a taker to me. Also, see the work the Web10G group is doing for > > Linux: http://www.web10g.org > > RFC 4989 doesn't seem to officially exist. Ah, it's 4898. Bargh. How did I get a typo in there? :) > Yes, RFC4898 seems to contain a lot of interesting information, question > is how to destill this down to something the user can understand and that > is of interest for a support engineer who might be trying to diagnose the > customer problem. > > I agree web10g seems to be of interest as well. I'm going to read through > their documents tomorrow. I recently got the web10g folks and the Linux kernel and networking folks talking to each other, it may get upstreamed in the reasonably near future. I'll make sure somebody keeps this list informed pgp912if8_sFU.pgp Description: PGP signature
Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
[Plug alert] For longer term monitoring, Project BISmark provides an easy-to-use system. It's an open source, customizable OpenWRT-based home router that runs periodic network measurements (latency, throughput, packetloss, jitter, etc) to nearby MLab servers. It uses netperf (single and multiple TCP threads), and shaperprobe, (UDP) for throughput measurements. Although its original target audience is home users, it can also be used as a monitoring tool in bigger networks. More information here: http://projectbismark.net/ Slides from the talk at NANOG 53: https://www.nanog.org/meetings/nanog53/presentations/Monday/Sundaresan.pdf - Srikanth On 04/04/2013 06:45 AM, Steve Haavik wrote: >> It'd be nice to know if NDT was not accurate as well. Anyone tested it? > > We've been using it for a few years. On my laptop that runs linux I get > fairly consistent results (around 935Mb/s up and down right now) over a > 1Gig routed link (a couple routers and a firewall in between.) On the > Windows boxes I usually see a 100 to 200 Mb/s drop on the upload side. > The last time I checked, you can compile a commandline version of the > client. I seem to remember the commandline client not taking quite as > bad a hit on the tests compared to running it on linux, but it's been a > while since I tried it. > > For us it's been way more accurate than the various speedtest servers > our customers insist on trying. A while back I switched from compiling > my own kernel and NDT to using perfSONAR-PS > (http://psps.perfsonar.net/). I like that they've got live-cd and > net-install versions. If nothing else it's useful for pointing out the > difference between a local network issue and Internet Suckage. > >
Re: route for linx.net in Level3?
Yes. In the fallout from the Cloudflare attack of last week it was announced that several IXs were going to stop advertising the address space of their peering lan, which properly does not need to be advertised anyway. Yes, that will cause some minor problems for those who work for and with the companies that peer there, but they are *clients*, and should be able to have other similar arrangements made for them. Cheers, -- jra - Original Message - > From: "Yang Yu" > To: k...@network-services.uoregon.edu > Cc: "NANOG list" > Sent: Wednesday, April 3, 2013 7:20:44 PM > Subject: Re: route for linx.net in Level3? > I noticed it too this morning from a AS3549 customer. Level 3 LG shows > no route for 195.66.232.0/22 on North American sites. > > On Wed, Apr 3, 2013 at 6:52 PM, John Kemp > wrote: > > > > Having trouble reaching route-views.linx.routeviews.org from AS3582. > > > > I'm assuming that some folks stopped carrying > > this particular linx.net address prefix > > as of this morning. ?!? > > > > $ whois -h whois.cymru.com " -v 195.66.241.146" > > AS | IP | BGP Prefix | CC | Registry | > > Allocated | AS Name > > 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | > > 1997-12-01 | LINX-AS London Internet Exchange Ltd. > > > > $ dig +short 146.241.66.195.peer.asn.cymru.com TXT > > "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01" > > > > -- > > John Kemp (k...@routeviews.org) > > RouteViews Engineer > > NOC: n...@routeviews.org > > MAIL: h...@routeviews.org > > WWW: http://www.routeviews.org > > -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: route for linx.net in Level3?
In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote: > Yes. In the fallout from the Cloudflare attack of last week it was > announced that several IXs were going to stop advertising the > address space of their peering lan, which properly does not need to > be advertised anyway. Well, now that's a big maybe. I was a big advocate for the peering exchanges each having their own ASN and announcing the peering block back in the day, and it seems people may have forgotten some of the issues with unadvertised peering exchange blocks. It breaks traceroute for many people: The ICMP TTL Unreachable will come from a non-routed network (the exchange LAN). If it crosses another network boundary doing uRPF, even in loose mode, those unreachables will be dropped. It also reduces the utility of a tool like MTR. Without the ICMP responese it won't know where to ping, and even if it receives the ICMP it's likely packets towards the LAN IP's will be dropped with no route to host. It has the potential to break PMTU discovery for many people: If a router is connected to the exchange and a lower MTU link a packet coming in with DF set will get an ICMP would-fragment reply. Most vendors source from the input interface, e.g. the exchange IP. Like the traceorute case, if crosses another network boundary doing uRPF, even in loose mode, those ICMP messages will be lost, resulting in a PMTU black hole. Some vendors have knobs to force the ICMP to be emitted from a loopback, but not all. People would have to turn it on. But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway. Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure. How about we all properly implement BCP 38 instead? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpfLwy5Hpdxc.pgp Description: PGP signature
Re: route for linx.net in Level3?
On Thu, Apr 4, 2013 at 12:29 PM, Leo Bicknell wrote: > > But hey, this is a good thing because a DDOS caused issues, right? > Well, not so much. Even if the exchange does not advertise the > exchange LAN, it's probably the case that it is in the IGP (or at > least IBGP) of everyone connected to it, and by extension all of > their customers with a default route pointed at them. For the most > popular exchanges (AMS-IX, for instance) I suspect the percentage > of end users who can reach the exchange LAN without it being > explicitly routed to be well over 80%, perhaps into the upper 90% > range. So when those boxes DDOS, they are going to all DDOS the > LAN anyway. Yes, thats why everyone needs to set up some sanity in their networks. This was presented at an APNIC conference a little while back: http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf hundreds of networks are improperly set up and are being abused (and abusing) to the IXP LANs. > > Security through obscurity does not work. This is going to annoy some > people just trying to do their day job, and not make a statistical > difference to the attackers trying to take out infrastructure. This isn't security through obscurity. This is saving the IXP from getting 100's of G's over transit, which should just be for their corporate network. > > How about we all properly implement BCP 38 instead? Agree.
Re: route for linx.net in Level3?
Leo Bicknell wrote: Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. Actually, that may not be the case, and probably *should* not be the case. Here's why, in a nutshell: If two regional ISPs on either side of the planet, point default to the same Global ISP, even if they do not peer with that ISP, by using the IX next-hop at IX A (for ISP A), and IX B (for ISP B), then the Global ISP is now giving free on-net transit to A and B. So, it turns out that pretty much the only way to prevent this at a routing level, is to not carry IXP networks (in IGP or IBGP), but rather to do next-hop-self. The other way is to filter at a packet level on ingress, based on Layer 2 information, which on many kinds of IX-capable hardware, is actually impossible. So, when it comes to IXPs: Next-Hop-Self. (BCP 38 actually doesn't even enter into it, oddly enough.) Brian
Re: route for linx.net in Level3?
On 2013-04-04, at 15:53, Brian Dickson wrote: > Leo Bicknell wrote: > > Even if the exchange does not advertise the > exchange LAN, it's probably the case that it is in the IGP (or at > least IBGP) of everyone connected to it, I have experience of several networks where that is not the case. IGP carries routes for loopback and internal-facing interfaces; external-facing interface routes are only known to the local router; pervasive next-hop-self for IBGP. So, no great survey, but don't assume that everybody does things the same way. Joe
RE: route for linx.net in Level3?
First of all I agree with Leo that not advertising IX prefixes permanently causes more problems than it solves. > Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it Well if I would peer with such an ISP at London and Frankfurt I could create a GRE tunnel from London to Frankfurt via the other ISP and use it to transport packets that would otherwise have to traverse my backbone. Or if my peer has a router at IX that happens to have full routing view I can just point a static default toward it and have a free transit. Check out: http://www.bcp38.info adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Thursday, April 04, 2013 9:29 PM To: NANOG Subject: Re: route for linx.net in Level3? In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote: > Yes. In the fallout from the Cloudflare attack of last week it was > announced that several IXs were going to stop advertising the address > space of their peering lan, which properly does not need to be > advertised anyway. Well, now that's a big maybe. I was a big advocate for the peering exchanges each having their own ASN and announcing the peering block back in the day, and it seems people may have forgotten some of the issues with unadvertised peering exchange blocks. It breaks traceroute for many people: The ICMP TTL Unreachable will come from a non-routed network (the exchange LAN). If it crosses another network boundary doing uRPF, even in loose mode, those unreachables will be dropped. It also reduces the utility of a tool like MTR. Without the ICMP responese it won't know where to ping, and even if it receives the ICMP it's likely packets towards the LAN IP's will be dropped with no route to host. It has the potential to break PMTU discovery for many people: If a router is connected to the exchange and a lower MTU link a packet coming in with DF set will get an ICMP would-fragment reply. Most vendors source from the input interface, e.g. the exchange IP. Like the traceorute case, if crosses another network boundary doing uRPF, even in loose mode, those ICMP messages will be lost, resulting in a PMTU black hole. Some vendors have knobs to force the ICMP to be emitted from a loopback, but not all. People would have to turn it on. But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway. Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure. How about we all properly implement BCP 38 instead? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: route for linx.net in Level3?
>> Even if the exchange does not advertise the exchange LAN, it's >> probably the case that it is in the IGP (or at least IBGP) of >> everyone connected to it, yikes! this is quite ill-advised and i don't know anyone who does this, but i think all my competitors should. > I have experience of several networks where that is not the case. IGP > carries routes for loopback and internal-facing interfaces; i have seen some carry external because, for some reason, they do not want to re-write next-hop at the border. randy
Re: route for linx.net in Level3?
On Thu, Apr 4, 2013 at 1:26 PM, Adam Vitkovsky wrote: > Check out: http://www.bcp38.info Right on. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Wells Fargo getting DDoSed ?
I observed that since morning Wells Fargo web services are either not reachable or are really slow. I think they are getting DDoSed again. Any official information yet ? Regards, -Jay. -- "Subvert the paradigm." - C.K. Prahlad
Microsoft Email Admin
Can a Microsoft email admin contact me off list in regards to issues emailing a few of our domains? Thanks, Cody
Re: route for linx.net in Level3?
Yeah, you wouldn't think that one should fall out. It is possible that my 195.66.241.146 really should be something sitting within: 195.66.232.0/22. I'll have to talk with some of the LINX folks to understand whether they are intending that 195.66.240.0/22 and 195.66.232.0/22 are treated differently. If that's the case, I may need to move off of 195.66.240.0/22. Thanks, John Kemp (k...@routeviews.org) On 4/3/13 4:20 PM, Yang Yu wrote: > I noticed it too this morning from a AS3549 customer. Level 3 LG shows > no route for 195.66.232.0/22 on North American sites. > > On Wed, Apr 3, 2013 at 6:52 PM, John Kemp > wrote: >> >> Having trouble reaching route-views.linx.routeviews.org from AS3582. >> >> I'm assuming that some folks stopped carrying >> this particular linx.net address prefix >> as of this morning. ?!? >> >> $ whois -h whois.cymru.com " -v 195.66.241.146" >> AS | IP | BGP Prefix | CC | Registry | >> Allocated | AS Name >> 5459| 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | >> 1997-12-01 | LINX-AS London Internet Exchange Ltd. >> >> $ dig +short 146.241.66.195.peer.asn.cymru.com TXT >> "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01" >> >> -- >> John Kemp (k...@routeviews.org) >> RouteViews Engineer >> NOC: n...@routeviews.org >> MAIL: h...@routeviews.org >> WWW: http://www.routeviews.org >>
Re: route for linx.net in Level3?
On Thu, Apr 4, 2013 at 1:43 PM, Randy Bush wrote: >>> Even if the exchange does not advertise the exchange LAN, it's >>> probably the case that it is in the IGP (or at least IBGP) of >>> everyone connected to it, > > yikes! this is quite ill-advised and i don't know anyone who does > this, but i think all my competitors should. > Its more common than uncommon. At WIX (Wellington), 64 out of 93 members will carry packets destined to APE (Auckland Exchange). (source: http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf) and this is just New Zealand! Just checked a few exchanges, not just are the IXP ranges being carried, they're being leaked: Equinix SG: $ bgpctl show rib 202.79.197.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin 202.79.197.0/24 100 0 13335 23947 23947 ? 202.79.197.0/24 100 0 13335 10026 i Any2 LA: bgpctl show rib 206.223.143.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin 206.223.143.0/24 100 0 13335 9304 i 206.223.143.0/24 100 0 13335 9304 i 206.223.143.0/24 100 0 13335 4635 9304 i 206.223.143.0/24 100 0 13335 9304 i >> I have experience of several networks where that is not the case. IGP >> carries routes for loopback and internal-facing interfaces; > > i have seen some carry external because, for some reason, they do not > want to re-write next-hop at the border. > > randy >
Re: route for linx.net in Level3?
> On Thu, Apr 4, 2013 at 1:43 PM, Randy Bush wrote: Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, >> >> yikes! this is quite ill-advised and i don't know anyone who does >> this, but i think all my competitors should. >> > > Its more common than uncommon. > > At WIX (Wellington), 64 out of 93 members will carry packets destined > to APE (Auckland Exchange). (source: > http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf) > and this is just New Zealand! > > Just checked a few exchanges, not just are the IXP ranges being > carried, they're being leaked: i am not unhappy by the exchange mesh being carried within a member and being propagated to their customer cone, see my nanog preso of feb 1997 and leo's recent post. it's putting such things in one's igp that disgusts me. as joe said, igp is just for the loopbacks and other interfaces it takes to make your ibgp work. randy
Re: route for linx.net in Level3?
In a message written on Fri, Apr 05, 2013 at 10:01:34AM +0900, Randy Bush wrote: > it's putting such things in one's igp that disgusts me. as joe said, > igp is just for the loopbacks and other interfaces it takes to make your > ibgp work. While your method is correct for probably 80-90% of the ISP networks, the _why_ people do that has almost been lost to the mysts of time. I'm sure Randy knows what I'm about to type, but for the rest of the list... The older school of thought was to put all of the edge interfaces into the IGP, and then carry all of the external routes in BGP. This caused a one level recursion in the routers: eBGP Route->IXP w/IGP Next Hop->Output Interface The Internet then became a thing, and there started to be a lot of BGP speaking customers (woohoo! T1's for everyone!), and thus lots of edge /30's in the IGP. The IGP convergence time quickly got very, very bad. I think a network or two may have even broken an IGP. The "solution" was to take edge interfaces (really "redistribute connected" for most people) and move it from the IGP to BGP, and to make that work BGP had to set "next-hop-self" on the routes. The exchange /24 would now appear in BGP with a next hop of the router loopback, the router itself knew it was directly connected. A side effect is that this caused a two-step lookup in BGP: eBGP-Route->IXP w/Router Loopback Next Hop->Loopback w/IGP Next Hop->Output Interface IGP's went from O(bgp_customers) routes to O(router) routes, and stopped falling over and converged much faster. On the flip side, every RIB->FIB operation now has to go through an extra step of recursion for every route, taking BGP resolution from O(routes) to O(routes * 1.1ish). Since all this happened, CPU's have gotten much faster, RAM has gotten much larger. Most people have never revisited the problem, the scaling of IGP's, or what hardware can do today. There are plenty of scenarios where the "old way" works just spiffy, and can have some advantages. For a network with a very low number of BGP speakers the faster convergence of the IGP may be desireable. Not every network is built the same, or has the same scaling properties. What's good for a CDN may not be good for an access ISP, and vice versa, for example. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp7nvnvQHk2B.pgp Description: PGP signature
Re: 80 km BiDi XFPs
Closest I've seen is 60km. I would be interested to hear if someone knows of an 80km option. http://www.fiberstore.com/new-xfp-bidi-10gbps-single-mode-60km-1330nmtx-127 0nmrx-transceiver-module-p-13175.html -- Brandon Robare Network Engineer, NoaNet c: 503.798.1515 noc: 866.662.6380 | n...@noanet.net On 4/2/13 4:15 PM, "Frank Bulk" wrote: >Is anyone aware of a reputable supplier of 80 km BiDi XFPs? My regular >supplier of generics doesn't have an option for us, but I would really >like >to avoid leasing additional fibers. > >Frank > > >
RE: Wells Fargo getting DDoSed ?
I have been having issues with their iPad App all day -Original Message- From: Jayram Déshpandé [mailto:jayde...@gmail.com] Sent: Thursday, April 4, 2013 4:38 PM To: nanog@nanog.org Subject: Wells Fargo getting DDoSed ? I observed that since morning Wells Fargo web services are either not reachable or are really slow. I think they are getting DDoSed again. Any official information yet ? Regards, -Jay. -- "Subvert the paradigm." - C.K. Prahlad
