Enterprise network as an ISP with a single huge customer

Tim Raphael raphael.timothy at gmail.com
Sat Jun 13 03:00:19 UTC 2015


It will also depend greatly on the knowledge of the design team / person and the operations team. If the designer is ex-SP or has a strong knowledge of both SP and Enterprise then yes, a good design may result.

There are plenty of people out there that will use MPLS / multiple tables for the wrong reasons just so they can say that's what they're doing.

Regards,

Tim Raphael

> On 13 Jun 2015, at 10:48 am, Stepan Kucherenko <twh at megagroup.ru> wrote:
> 
> 13.06.2015 05:35, Randy Bush wrote:
>>>> i have seen a lot of this done with firewall devices and vlans.  with
>>>> vlans or mpls, you can make spaghetti without wires, one wheat and one
>>>> semolina.
>>> 
>>> oh absolutely. you can use many tools to lop off your fingers, my
>>> point was that things like mpls (or vlans) provide a nice other tool
>>> to use along with your firewalls and such.
>>> 
>>> of course you ought not willy-nilly go crazy with this, but... imagine
>>> if the 'hr department' were in one contiguous 'VRF' which had a
>>> defined set of 2-3 exit points to control access through... while
>>> those willy 'engineers' could be stuck in their own ghetto/VRF and
>>> have a different set of 2-3 exit points to control.
>>> 
>>> Expand your network over many locations and in large buildings and ...
>>> it can be attractive to run a 2547 network that the company is a
>>> 'customer' of, or so I was thinking :)
>> 
>> i have seen people successful with this with mpls and with vlans with
>> non-mpls tunnel tech (e.g. ipsec for the paranoid).  i have seen them
>> screw the pooch with both.
>> 
>> randy
> 
> You can compartmentalize your network in lots of ways. What I'd like to know is what ways failed harder in other peoples experience (or at least faster).
> 
> I'm not sure doing it ISP style is better, but I think it has some benefits. Then again, the opposite is true as well, less complexity means more stability. Usually.



More information about the NANOG mailing list