Re: Cogent peering issues with Sprint
On Wed, Oct 10, 2007 at 11:00:13AM -0400, Marshall Eubanks wrote: > Are you sure that this is not in Sprint, or even Duke Energy ? > > I can't ping to 192.234.122.137 from either home or work, and I don't > see any signs of Cogent problems > from Tyco Road / Tysons Corner. It would seem that this issue with Sprint's been resolved. -Basil @ CIFNet
Re: Cogent peering issues with Sprint
On Wed, Oct 10, 2007 at 09:38:42AM -0500, [EMAIL PROTECTED] wrote: > Cogent is experiencing two problems right now. Their automated message > reports that they have a backbone problem causing latency, but they also > seem to be experiencing peering problems with Sprint. > > 2 g1-0.core01.ord01.atlas.cogentco.com (66.28.6.73) [AS 174] 0 msec 0 > msec 0 msec > 3 t4-1.mpd01.ord01.atlas.cogentco.com (154.54.1.98) [AS 174] 4 msec 0 > msec 0 msec > 4 v3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) [AS 174] 0 msec 0 > msec 0msec > 5 g6-0-0-3492.core01.ord03.atlas.cogentco.com (154.54.3.241) [AS 174] 0 > msec 0 msec 0 msec > 6 sprint.ord03.atlas.cogentco.com (154.54.13.46) [AS 174] 0 msec 4 msec > 0 msec > 7 sl-bb20-chi-4-0.sprintlink.net (144.232.8.218) [AS 174] 0 msec 0 msec > 0 msec > 8 sl-bb21-chi-15-0.sprintlink.net (144.232.26.2) [AS 174] 4 msec 4 msec > 0 msec > 9 sl-bb25-chi-13-0.sprintlink.net (144.232.26.90) [AS 174] 0 msec 0 msec > 0 msec > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * We're actually seeing the same isses @ NTT/AS2914 peering with Sprint/AS1239: traceroute to www.sprint.net (199.0.234.48), 64 hops max, 40 byte packets 1 10.30.1.1 (10.30.1.1) 0.504 ms 0.221 ms 0.234 ms 2 ge-2-2-0.r00.chcgil08.us.bb.gin.ntt.net (129.250.208.1) 0.298 ms 0.290 ms 0.284 ms 3 p16-0-2-3.r21.chcgil09.us.bb.gin.ntt.net (129.250.3.17) 0.469 ms 0.474 ms 0.452 ms 4 ae-0.r20.chcgil09.us.bb.gin.ntt.net (129.250.3.97) 0.423 ms 0.421 ms 0.418 ms 5 sl-st21-chi-14-1-1.sprintlink.net (144.232.8.221) 0.408 ms 0.439 ms 0.414 ms 6 sl-crs2-chi-0-0-0-3.sprintlink.net (144.232.26.9) 1.661 ms 1.521 ms 1.407 ms 7 sl-bb25-chi-8-0.sprintlink.net (144.232.26.113) 1.264 ms 1.212 ms 1.075 ms 8 * * * ^C -Basil @ CIFNet
Re: Protecting inbound interfaces (re: Cisco exploit)
On Fri, Jul 18, 2003 at 06:07:08AM -0700, Rick Ernst wrote: > > > Is there a way to globally protect all inbound interfaces on a router via ACL > (specifically hundreds of frame/sub-interfaces) without applying the same ACL > to each individual interface? I believe something like this will work: no access-l 198 access-list 198 deny 53 any any log-input access-list 198 deny 55 any any log-input access-list 198 deny 77 any any log-input ! access-list 198 permit pim host xx.xx.xx.xx 224.0.0.0 31.255.255.255 ! access-list 198 deny pim any any log-input access-list 198 permit ip any any ! !end replace xx.xx.xx.xx with real ip address if you have PIM running, if you don't, remove that line. > Is the "line vty" config only for telnet/ssh, etc. or is it the magic global > that I'm looking for? No. I don't think so. -Basil @ CIFNet
Re: AOL & Cogent
On Mon, Dec 30, 2002 at 08:14:45AM -0500, Omachonu Ogali wrote: > > For my not-so-bright customers I simply want traceroutes to look good when > > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > > really disturbing, try to explain to one of them that there is no problem. > > Then make a press release for your not so bright customers, and explain > every single detail rather than asking a company to change their entire > routing policy because you're too lazy to educate your customers on how > traceroute shouldn't be used as a tool to gauge performance. And if you > can't explain it to them, then you should step back and look at who you > really have for customers. "Enough said." Great. Thanks for the PR tip. I never intended them to change "their entire routing policy" just for my laziness, if you insist ;) It's been going on for 2 and 1/2+ weeks with no definitive date/solution/workaround on when it's going to be fixed. Now I've made an attempt trying to show what could be done; perhaps move some butts to actually get something done. Speaking of my customers or perspective customers, I don't get to choose often who they are. Maybe you do, I don't. Happy New Year, -Basil
Re: AOL & Cogent
On Sat, Dec 28, 2002 at 09:45:21PM -0500, Richard A Steenbergen wrote: > > 2. I think I asked this before, why wouldn't Cogent prepend > > customer prefixes to Level3 or set BGP4 community for multihomed sites, > > homed w/ Cogent + someone else. > > You got your answer to this before, what part wasn't clear? Cogent isn't > congested in the inbound direction, only outbound to Level 3. The best > they could do is lower their localpref for 3356, which I would surely hope > they have done already. I understand very well that there is no problem on the inbound of Cogent from Level3. For my not-so-bright customers I simply want traceroutes to look good when they run one from Level3-homed site. Obviously a ~5-7 hops to us looks really disturbing, try to explain to one of them that there is no problem. Enough said. -Basil
Re: AOL & Cogent
Speaking of this whole Cogent/AOL/Level3 mess.. sigh. I got tired of trying getting anything out of Cogent. So, here's list of questions perhaps someone might be able to answer. 1. I'm sure some of you are customers of Level3, and I'm sure you do see 1-2 sec latency w/ Cogent, what's the official Level3 'position' if/when you contact them? Do they have any plans upgrading capacity with Cogent, what's their side of this story in general? 2. I think I asked this before, why wouldn't Cogent prepend customer prefixes to Level3 or set BGP4 community for multihomed sites, homed w/ Cogent + someone else. (This is to control inbound, and please don't go into "this is not-standard and Cogent won't do it".) 3. Did anyone suggested to Cogent to carry traffic (or some portion of it) to AOL via MFN to offload its Level3 peering? I couldn't get any straight answer from Cogent why this can't be done. 4. And another interesting perspective... I'm sure NDAs on peering are involved, but anyhow -some of us don't really care about AOL that much, assuming it is only outbound from Cogent into AOL (via Level3) that is saturated, Cogent may try to push traffic as: 16631_174_3356_ excluding AOL' ASN(s) at one peering location and keep saturating its Level3 peering connectivity at other locations. Any thoughts? -Basil
Re: Cogent and Level3 Peering Issues
On Wed, Dec 18, 2002 at 03:23:04PM -0500, [EMAIL PROTECTED] wrote: > > > > Me thinks Cogent doesn't have a problem with congestion on the inbound > > > direction. Fix your reverse path. > > > > Customers of Cogent should be/are more concerned about congestion on the > > inbounds at Level3 <-> Cogent; outbound is way too easy to control. > > Cogent has a pile of available inbound - websites tend to send traffic out, > not take traffic in. Somewhat true. Yet still if the inbound from one of the major players is really saturated wouldn't that hurt Cogent customers. -Basil
Re: Cogent and Level3 Peering Issues
On Wed, Dec 18, 2002 at 02:36:04PM -0500, Richard A Steenbergen wrote: > > Why wouldn't Cogent create a community string to provide its multihomed > > customers with prepend 16631 (or customer asn) to Level3 peering sessions > > to control inbounds better? > > Me thinks Cogent doesn't have a problem with congestion on the inbound > direction. Fix your reverse path. Customers of Cogent should be/are more concerned about congestion on the inbounds at Level3 <-> Cogent; outbound is way too easy to control. If the site is multihomed to any decent Tier1 provider +Cogent; (701 or 2914 or 1239 or 3561 or 1, etc +16631) with or without prepend 16631 or site ASN, a lot of, if not all of the inbound traffic will still be going through one of those better carriers, fortunately or unfortunately. All I really want is to be able to control my inbound from Level3 ;) -Basil
Re: Cogent and Level3 Peering Issues
On Wed, Dec 18, 2002 at 01:12:02PM -0500, Richard A Steenbergen wrote: > > On Wed, Dec 18, 2002 at 08:44:55AM -0800, [EMAIL PROTECTED] wrote: > > > > AOL (AS1668) stopped peering with cogent yesterday for reasons they did > > not disclose publicly. Cogent sends same letter to all customers who > > asked for what is going on and in the letter they say that two weeks > > ago, peering to AOL was upgraded to OC48 from OC12 and now for some > > reason AOL stopped peering and if somebody has questions they should call > > AOL to complain .. (with phone# to their NOC provided in the letter > > - not very nice thing to do it like this in my opinion). > > If nothing else, Cogent could be using their idle 6461 transit, instead of > grandstanding by overloading their Level 3 capacity so they can blame AOL. is it really idle ? Why wouldn't Cogent create a community string to provide its multihomed customers with prepend 16631 (or customer asn) to Level3 peering sessions to control inbounds better? -Basil
Re: Cogent bgp customers
On Tue, Nov 19, 2002 at 03:52:06PM -0600, Basil Kruglov wrote: > > policies. Please contact privately. Thanks in advance, > > Opps.. it's a typo, Cogent/AS16631. Quite a few people responded. Thanks everyone, -Basil @ CIFNet
Re: Cogent bgp customers
On Tue, Nov 19, 2002 at 03:30:24PM -0600, Basil Kruglov wrote: > Sorry for the off topic and I apologize in advance. > > But can someone who's got IP transit and BGP session with Cogent/AS11418 get > in touch with me? I have a few really quick questions in re to their BGP > policies. Please contact privately. Thanks in advance, Opps.. it's a typo, Cogent/AS16631. -Basil
Cogent bgp customers
Sorry for the off topic and I apologize in advance. But can someone who's got IP transit and BGP session with Cogent/AS11418 get in touch with me? I have a few really quick questions in re to their BGP policies. Please contact privately. Thanks in advance, -Basil @ CIFNet
Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote: > On Wed, 1 May 2002, Wojtek Zlobicki wrote: > > > > Where are providers drawing the line ? Anyone have somewhat detailed > > published policies as to what a provider can do in order to protect their > > nework as a whole. > > At what point (strength of the attack) does a customers netblock (assuming a > > /24 for > > example) get null routed by whichever party. > > Most providers likely have a policy similar to: "I can't sacrafice 1 > my network for 1 customer". So, if the attack is sufficient to degrade > service on the ISP network most likely the customer under attack will get > null routed. Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just for the sake of the argument), UU will not null route my ircd if it it gets attacked on regular basis, say *daily* ? Furthermore you are going to consistently place filters on your routers, take them out within the 24h (or whatever then-current policy of UUnet is) and track attacks back to their sources within the boundaries of your backbone on a daily basis? ;) Will you do that for say a regular T1 customer or do I need more "commitment" as sales droids like to put it, to even consider such a service ? ;) > Hmm, perhaps FIRST customers should insist that their ISP have some 24/7 > security contact that can actually help in the case of an attack. Today > there are very few that have this capability. I'd say from personal > experience that the number is way too small, even in the 'large' ISP arena > :( > > More pressure from customers for real security would be a good start. sigh, tried and failed, miserably I might add. -Basil
Re: Economics of flooding
On Tue, Apr 02, 2002 at 10:06:58AM -0800, Livio Ricciulli wrote: > Is anyone aware of a process for claiming a deduction in charges when > fees are associated with a flooding attack? > In particular, attacks may push up the 95% usage or (more commonly) > attacks may create prolonged > loss of network availability; Both outcomes may result in a claim for > deduction. This goes to big-boys - it's easier to kick the customer out then to deal with it, especially if you're running an irc server or similar things like customers hosting shells/bots/etc. > Has anyone ever dealt with something like this? How is this handled > today? What evidence or proof has > to be provided to get the deductions (if any)? In general, if you say commit to say 20-30Mbps+ on 95th % up to 100Mbps burstable, they will ask how often those attacks happen, if it's <5-10 a month, then it's nothing, regardless how hard you get hit, just make sure to give them a call and request filters if it's above your 95th % line. If you get 5+ weekly or *daily* and if NSP cannot put some semi-permanent solution, other than some pathetic 24h policy or alike, then eventually they *will* stop working with you. They have other customers and issues attend to and they will not break the 24h-acl policy rule for just one customer. If those attacks overrun their pipes or cpu in routers, thus causing the downtime, downtime = SLA credits to other customers; and if they can't work with their peers/transits or peers/transits refuse to work with your NSP, then at some point they will stop working with you or/and kick you out per contract/AUP - been there, done that. Of the top of my head, not UUnet, C&W, Sprint, Genuity, Exodus, Globix, Verio, to name a few, will go thus far to fix the billing issue, they have different chain of people working at each level/department, they might bend once but that's as far as it goes. 9 out of 10 times they'll ask you to commit to more transit or/and get a flat pipe. It's about making $ at the end, always, never forget. -Basil
Re: Exodus De-Peering
On Sun, Mar 31, 2002 at 07:16:06PM -0500, Alex Rubenstein wrote: > So, the Friday of Exodus de-peering has passed. > > First of all, has it happened? well, Verio customers are getting through C&W to Exodus networks. Yet OpenTransit customers are still peering (if it's not transit ?) with Exodus. AT&T still peer with Exodus, yet Genuity customers has to go through C&W (one hop) to Exodus.. gblx still peer (if it's peering;) with Exodus.. -Basil
