<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head>

<body>

Hi Adam, <br>

<br>

Depends on how big of a router you need for your "small PE".<br>

<br>

Taking Juniper as an example, the MX204 is pretty unbeatable cost wise if you can make do with its 4*QSFP28 & 8*SFP+ interfaces. There's a very big gap between the MX204 and the first chassis based router in the MX lineup, even if you only try to replicate

 the port configuration at first. <br>

<br>

Best regards, <br>

Martijn <br>

<br>

PS, take note of the MX204 port profiles, not every combination of interface speeds is possible:

<a href="https://apps.juniper.net/home/port-checker/">https://apps.juniper.net/home/port-checker/</a><br>

<br>

<div class="gmail_quote">On 19 June 2019 22:22:45 CEST, adamv0025@netconsultings.com wrote:

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Hi folks,<br><br>Recently I ran into a peculiar situation where we had to cap couple of PE<br>even though merely a half of the rather big chassis was populated with<br>cards, reason being that the central RE/RP was not able to cope with the<br>combined number of routes/vrfs/bgp sessions/etc.. <br><br>So this made me think about the best strategy in building out SP-Edge<br>nowadays (yes I'm aware of the centralize/decentralize pendulum swinging<br>every couple of years).<br>The conclusion I came to was that *currently the best approach would be to<br>use several medium to small(fixed) PEs to replace a big monolithic chasses<br>based system.<br>So what I was thinking is, <br>Yes it will cost a bit more (router is more expensive than a LC)<br>Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care.<br>But the benefits are less eggs in one basket, simplified and hence faster<br>testing in case of specialized PEs and obviously better RP CPU/MEM to port<br>ratio.<br>Am I missing anything please?  <br><br>*currently,<br>Yes some old chassis systems or even multi-chassis systems used to support<br>additional RPs and offloading some of the processes (e.g. BGP onto those)<br>-problem is these are custom hacks and still a single OS which needs<br>rebooting LC/ASICs when being upgraded -so the problem of too many eggs in<br>one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are<br>an exception) <br>And yes there is the "node-slicing" approach from Juniper where one can<br>offload CP onto multiple x86 servers and assign LCs to each server (virtual<br>node) - which would solve my chassis full problem -but honestly how many of<br>you are running such setup? Exactly. And that's why I'd be hesitant to<br>deploy this solution in production just yet. I don't know of any other<br>vendor solution like this one, but who knows maybe in 5 years this is going<br>to be the new standard. Anyways I need a solution/strategy for the next 3-5<br>years.<br><br> <br>Would like to hear what are your thoughts on this conundrum.<br><br>adam <br><br>netconsultings.com<br>::carrier-class solutions for the telecommunications industry::   <br><br><br></pre>

</blockquote>

</div>

<br>

-- <br>

Sent from my Android device with K-9 Mail. Please excuse my brevity.

</body>

</html>