Comcast NOC contact
I'm seeing an odd routing issue with Comcast and would like their help. Does any have any contact information for them?
Re: Fiber outage in Miami
I've yet to hear back from them on the reason for the outage and explanation on why our "redundant" darkfiber pairs both were down. On Sat, Jan 28, 2012 at 2:23 PM, Jason LeBlanc wrote: > We got the same RFO. BS. > > > On 01/28/2012 01:36 PM, Randy Epstein wrote: > >> Anyone has seen on gotten a RFA or a deeper explanation of what >>> happened from them ? >>> >>> >>> Faisal Imtiaz >>> Snappy Internet& Telecom >>> 7266 SW 48 Street >>> Miami, Fl 33155 >>> Tel: 305 663 5518 x 232 >>> Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net >>> >> Yes. They blamed/burned the local crew and suggested that they fired >> them. Yes, they put this in the RFO. I have it, but I'm having legal >> determine if it can be made public record. >> >> Randy >> >> >> >> >
Route Management Best Practices
My network has grown large enough that maintaining my prefix announcements to the rest of the world has become increasingly difficult. I currently use static routes and tags on my edge routers to inject route into BGP. The tags correspond to communities that reflect how the routes are announced per region. I would love to heat from others on how they handle this.
Re: Route Management Best Practices
Thanks Mark What do you use for reflectors, hardware(Cisco/Juniper) or software daemons(Quagga)? I've been toying with the idea of using Quagga route servers to announce our prefixes to our edge routers and redistribute BGP annoucements learned from downstream customers. Only drawback is the lack of support for tagged static routes, so it looks like I'm going to have to use a network statement w/ route-map to set the attributes. Has anyone tried this, or is it suicide? On Tue, Jan 31, 2012 at 1:38 AM, Mark Tinka wrote: > On Tuesday, January 31, 2012 01:01:30 AM Joe Marr wrote: > > > I currently use static routes and tags on my edge routers > > to inject route into BGP. The tags correspond to > > communities that reflect how the routes are announced > > per region. > > > I would love to heat from others on how they handle this. > > We originate our allocations from our route reflectors. The > route reflectors make sense for a number of reasons, e.g., > they're always up, they aren't doing anything else, they > aren't in the forwarding path, they aren't reachable from > outside our AS, they're few enough to manage scalably, > e.t.c. > > Like you, we attach communities to all originated > allocations as the route reflector is announcing them to all > iBGP neighbors, and those communities are used to determine > how the routes are announced to peers, upstreams and > customers. > > The problem with originating your routes at the edge > (peering or customers) is you'll likely have more of these > routers than route reflectors, so redundancy management of > route origination will become a huge problem. > > Also, failure of your edge routers is probably more likely > than your route reflectors just by the very nature of their > functions. This is why most advice is not to originate > routes on routers that are providing inter-AS connectivity, > as it could lead to blackholes due to backhaul link failure. > > Cheers, > > Mark. >
Re: Route Management Best Practices
Thanks Mark, This helps and definitely shows Im heading in the right direction. Thanks, On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka wrote: > On Tuesday, January 31, 2012 03:04:15 PM Joe Marr wrote: > > > What do you use for reflectors, hardware(Cisco/Juniper) > > or software daemons(Quagga)? > > We operate 2x networks. > > One of them runs Cisco 7201 routers as route reflectors, > while the other runs Juniper M120 routers. > > The large Juniper routers were due to particular BGP AFI's > that Cisco IOS does not support (yet). > > > I've been toying with the idea of using Quagga route > > servers to announce our prefixes to our edge routers and > > redistribute BGP annoucements learned from downstream > > customers. > > You can certainly use any device in your network to > originate your allocations. We just use the route reflectors > because it is a natural fit, but you can use any device > provided it would be as stable and independent as a route > reflector. > > The last thing you want is a blackhole or a route going away > because your backhaul failed or your customer DoS'ed your > edge router :-). > > > Only drawback is the lack of support for > > tagged static routes, so it looks like I'm going to have > > to use a network statement w/ route-map to set the > > attributes. > > There was a time when networks were ran without prefix > lists, BGP communities or even route maps. I'm too young to > have ever experienced those times, but I always joke with a > friend (from those times) about how good we have it today, > and how hard life must have been for Internet engineers of > old :-). > > If you have the opportunity, I'd advise against operating > without these very useful tools. > > > Has anyone tried this, or is it suicide? > > I'm sure there are several networks out there that are > intimidated by additional BGP features such as communities, > advanced routing policy, e.t.c. They do survive without > having to deal with this, probably because they're networks > are small and the pain is better than trying something new. > But I certainly wouldn't recommend it to anyone (except, as > Randy would say, my competitors). > > Mark. >
Re: Route Management Best Practices
Thanks for the advice. Filtering and route manipulation hasn’t been a problem for me. I’m very careful to prevent leakage, etc. My current issue is scaling my management of our prefix announcements. Every time I add a new block, I need to modify all of my edge routers etc. I understand I can use IRR etc. to automate prefix-list deployments, but the blocks need to still be injected into the network? So my thought was to use a routeserver (quagga or a 7200) to do this. Im looking to understand how others handle this. On Tue, Jan 31, 2012 at 2:59 PM, Tony Tauber wrote: > To elaborate slightly on what others have said in terms of protecting > against leaks; > it's a good idea to filter outbound in a conservative way such that you > only send > what you "expect" in terms of community values and/or prefixes and/or > AS-paths. > > For instance, if something gets into your BGP that isn't tagged with one > of your expected > communities (e.g. applied where you inject your aggs), don't re-advertise > it. > If something has the right community, but not an expected AS-path (e.g. > contains the AS > of one of your transit providers), don't re-advertise. > Implicitly deny all unexpected cases. > > Building that kind of restrictive logic will be less likely to you > becoming a path for traffic you > didn't expect (and might swamp you) and also you'll be a better citizen in > general. > > Cheers, > Tony > > > On Tue, Jan 31, 2012 at 1:52 PM, Joe Marr wrote: > >> Thanks Mark, >> >> This helps and definitely shows Im heading in the right direction. >> >> Thanks, >> >> >> On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka > >wrote: >> >> > On Tuesday, January 31, 2012 03:04:15 PM Joe Marr wrote: >> > >> > > What do you use for reflectors, hardware(Cisco/Juniper) >> > > or software daemons(Quagga)? >> > >> > We operate 2x networks. >> > >> > One of them runs Cisco 7201 routers as route reflectors, >> > while the other runs Juniper M120 routers. >> > >> > The large Juniper routers were due to particular BGP AFI's >> > that Cisco IOS does not support (yet). >> > >> > > I've been toying with the idea of using Quagga route >> > > servers to announce our prefixes to our edge routers and >> > > redistribute BGP annoucements learned from downstream >> > > customers. >> > >> > You can certainly use any device in your network to >> > originate your allocations. We just use the route reflectors >> > because it is a natural fit, but you can use any device >> > provided it would be as stable and independent as a route >> > reflector. >> > >> > The last thing you want is a blackhole or a route going away >> > because your backhaul failed or your customer DoS'ed your >> > edge router :-). >> > >> > > Only drawback is the lack of support for >> > > tagged static routes, so it looks like I'm going to have >> > > to use a network statement w/ route-map to set the >> > > attributes. >> > >> > There was a time when networks were ran without prefix >> > lists, BGP communities or even route maps. I'm too young to >> > have ever experienced those times, but I always joke with a >> > friend (from those times) about how good we have it today, >> > and how hard life must have been for Internet engineers of >> > old :-). >> > >> > If you have the opportunity, I'd advise against operating >> > without these very useful tools. >> > >> > > Has anyone tried this, or is it suicide? >> > >> > I'm sure there are several networks out there that are >> > intimidated by additional BGP features such as communities, >> > advanced routing policy, e.t.c. They do survive without >> > having to deal with this, probably because they're networks >> > are small and the pain is better than trying something new. >> > But I certainly wouldn't recommend it to anyone (except, as >> > Randy would say, my competitors). >> > >> > Mark. >> > >> > >
