*nods* I was pretty sure you didn't. I thought you were a Cisco edge guy.
----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ken Hohhof" <af...@kwisp.com> To: "AnimalFarm Microwave Users Group" <af@af.afmug.com> Sent: Tuesday, September 24, 2019 8:08:38 PM Subject: Re: [AFMUG] Running MPLS I’m not saying I’m running full routes on a CCR. Just find the argument kind of amusing, it’s like the Coyote in the cartoon walking on air off the edge of the cliff until someone tells him he can’t do that and then he falls. From: AF <af-boun...@af.afmug.com> On Behalf Of Mike Hammett Sent: Tuesday, September 24, 2019 7:41 PM To: AnimalFarm Microwave Users Group <af@af.afmug.com> Subject: Re: [AFMUG] Running MPLS The problem is that I explain the problem and the people that disagree... still don't believe me. I just wasted my time, so I curtail my details the next time. This timing is a few years old... so it's going to be worse now. It's also why I have a larger range of time. I withdrew a route from the upstream device. It took 5 - 10 minutes for "/ip route print where" to reflect the route changed. It took a further 5 - 10 minutes for traceroutes to actually change paths. Taking 10 to 20 minutes to change how traffic flows is asinine in production. Most prefixes on the Internet aren't important... but when you blackhole a CDN prefix or something else people care about for 10 - 20 minutes... that's a problem. By the time you get the reports that it doesn't work, the router has converged and the problem has fixed itself. The problem is that you now look incompetent to your customer... and you think your customer is crazy. That's probably happening now and you don't even know it. What if there's an issue within one of your upstreams and their 750k routes now becomes 300 routes? Now you're blackholing a ton of the Internet for 10 - 20 minutes. All of this is easily avoidable... by not using CCRs in situations where you run full tables. ----- Mike Hammett Intelligent Computing Solutions Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender. Midwest Internet Exchange Image removed by sender.Image removed by sender.Image removed by sender. The Brothers WISP Image removed by sender.Image removed by sender. ----- Original Message ----- From: "Ken Hohhof" <af...@kwisp.com> To: "AnimalFarm Microwave Users Group" <af@af.afmug.com> Sent: Tuesday, September 24, 2019 7:17:17 PM Subject: Re: [AFMUG] Running MPLS Who are you going to believe, me or your lying eyes? From: AF <af-boun...@af.afmug.com> On Behalf Of Mike Hammett Sent: Tuesday, September 24, 2019 6:53 PM To: AnimalFarm Microwave Users Group <af@af.afmug.com> Subject: Re: [AFMUG] Running MPLS I do have access to a CCR doing full table BGP. It's a disaster. You don't need a $50k Juniper. You just need a $500 server with some 10G cards. By traffic flows, I mean Netflow, IPfix, etc. No, they don't. ----- Mike Hammett Intelligent Computing Solutions Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender. Midwest Internet Exchange Image removed by sender.Image removed by sender.Image removed by sender. The Brothers WISP Image removed by sender.Image removed by sender. From: "Darin Steffl" < darin.ste...@mnwifi.com > To: "AnimalFarm Microwave Users Group" < af@af.afmug.com > Sent: Tuesday, September 24, 2019 6:35:10 PM Subject: Re: [AFMUG] Running MPLS Mike, Unless you run CCR for your bgp routers, you can't say they don't work. We've been running bgp on our network for 3+ years with CCR's and it works. Convergence time is slower than a $50k Juniper sure but it doesn't affect us badly. Traffic flows smoothly and the only time it really takes time to converge is when we update firmware on the Tiks twice a year during our maintenance windows. When it's not downloading full tables the other 99.99% of the year, they move plenty of traffic happily without any performance issues. On Tue, Sep 24, 2019, 3:56 PM Mike Hammett < af...@ics-il.net > wrote: Anyone that says CCRs work fine with full routes doesn't know what they're talking about. ;-) Always take full tables so you have proper information for your traffic flows, uRPF, etc. ----- Mike Hammett Intelligent Computing Solutions Image removed by sender.Image removed by sender.Image removed by sender.Image removed by sender. Midwest Internet Exchange Image removed by sender.Image removed by sender.Image removed by sender. The Brothers WISP Image removed by sender.Image removed by sender. From: "Steve Jones" < thatoneguyst...@gmail.com > To: "AnimalFarm Microwave Users Group" < af@af.afmug.com > Sent: Tuesday, September 24, 2019 3:52:47 PM Subject: Re: [AFMUG] Running MPLS for now we take full bgp tables from each, and default route. then ospf distributes default if connected. We run rb1100ahx2 at all sites but the edges. those are ccr1072, i dont care what anybody says, theyve been handling the tables just fine for over a year even with the one core pegged when taking the tables. The 1100s are sufficient for what we are doing, but id like to put 1072s wherever there are redundant paths. bringing the full or aggregated tables in would be nice. thats what i was asking about, if mpls would be what i needed to hop over the 1100s since the underlying network is ospf On Tue, Sep 24, 2019 at 3:45 PM Seth Mattinen < se...@rollernet.us > wrote: <blockquote> On 9/24/19 1:21 PM, Cassidy B. Larson wrote: > Dont bother importing all the 760k routes learned from your upstream > providers into your core. Having that many routes is only going to > impact your egress traffic to the Internet, which is probably a drop in > the bucket compared to your ingress traffic loads (Netflix, CDNs, etc). > Just advertise a default route into the core from both providers and > your core can figure out which way to go to get to the Internets. If you're multihoming you really should consider a full feed, depending on how much you like to sleep. A couple weeks ago, a carrier POP that I and some of my customer use had an issue where their transport carrier died in a way that took down all transports. The carrier's POP router was still up, as was BGP and interfaces, but if you looked at the BGP neighbors there were only a handful of routes coming from them. Relying on a default route effectively sending your traffic into a black hole, whereas if you'd been routing based on prefixes you'd stop sending traffic as the prefixes withdrew when it became islanded. I didn't even notice until the carrier called me on the emergency number and said hey we can't reach our equipment, and I was like that's odd because your interface+BGP is still up but I'm only seeing a few prefixes from you, at which point the larger transport issue was discovered. ~Seth -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com </blockquote> -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
