So we've got a relatively small carrier network, where most of our traffic is traditional L3VPN CE to CE traffic, and only a tiny minority of the traffic (measured as actual throughput as well as in terms of port capacity, etc) is internet bound and directly handed off to our upstream providers.
For simplicity's sake, lets forget that there's an existing network, and just think about this in terms of green field only for now. Also assume we're *not* talking about full tables here, thousands of prefixes at max, not 10s or 100's of thousands. Customers are generally substantially fewer that that.
My instinct is to just treat the customers and upstream providers as basically equivalent. They're just another AS we have to deal with, so we they get a VRF / L3VPN. If one of our customers needs access to that AS, then we leak the routes like we do like any other.
With a model like that, where traffic to/from the Internet is ultimately crossing the same MPLS core as site to site traffic, is there any reason to have a dedicated ASBR facing ?
The arguments I've seen in favor of this generally fall into the following camps and my general feelings about each. But I'm generally uncertain if I'm being reasonable here. What do you guys think?
- DDOS - If a customer makes the Internet mad and we get an F-Ton of traffic, we imperil our core infrastructure. To my mind this boils down to "well, we don't have the scale to build a totally air-gapped network for this purpose, so... we're accepting that risk regardless. CoPP et. al. to the rescue I guess. If that's not enough, then we talk to our upstreams about real DDOS mitigation and make the decision to either pay for it or not.
- Other Security Concerns - if there's a zero-day remote-code-exploit (of 10,000 day RCE we haven't patched yet) then you've got access to the whole network. Generally, again, "we can't build an airgapped network so no matter how many layers of adjacent routers you stack on, ultimately if they can get into one, and as long as they share, at least, a management network, then you'll always have some ability to leverage one device to get into the others. Management ACLs and security best-practices are the only real answer you're going to get here"
- Redundancy - Many customers don't want those two services to share so much fate. I totally buy that, and we already make a point of spreading a given customer around a bit across the PEs at a given POP, but really I think the answer to that is the *opposite* of "put all your internet facing circuits over here, and all your customer circuits over there". If you need n routers to have the right amount of redundant capacity for a given use-case... then make sure you've got the right number of devices and circuits to meet that need with the appropriate amount of redundancy.
Are there other facets of this or some shared context I'm missing? Most of the engineers I heard this from originally were... "broadly unaware of modern best practices" to put it gently, but I've also seen similar sentiment mentioned here, and had customers ask the specific question of "do you have dedicated internet gateways" and it's making me think I'm missing something here. Is there some strategic blunder I'm making here? Or some other common architectural failure other providers have made in the past that customers are referencing?
EDIT: Also, of course, assume that capacity is not at issue. Obviously if we don't have the raw speeds/feeds to handle the new capacity represented by an internet circuit then... yeah... you probably end up buying new hardware to take that load. Again, the number of prefixes and overall share of traffic is quite small. Not negligible, but say in the 10 - 30% range.
No comments:
Post a Comment