Routing

Good Day,

Looking for some guidance on the best practise to transition a current campus core running as a MX VC to an EVPN collapsed spine core using MX304. Due to the simplicity in design with the current VC the L2 and L3 is simple for now, as you treat and configure the MX VC as "one" device. We now need to transition to EVPN with the least required design changes on the surrounding devices, so meaning as close as possible to a "VC" like experience. The challenge is the current environment is not just L2 but L3 between physically core and firewalls with p2p OSPF and BGP on the lo0. The L2 part is fine, however some complexity and redesign will be required because routing will now be between two routers and not "one" and also this routing needs to happen inside the overlay etc. Can anyone share their experience in a similar project or deployment and of there are challenges or best practises to look out for. Below is a sample diagram of the current environment and what I presume it will look like after. NOTE: No need to highlight any inconsistences in the drawing as it is only for demonstration but is am sure the idea is very clearly indicated.

Interesting project, familiar remit (limited changes to surrounding devices). Maybe you should call my employer, Telent Network Services.

An EVPN "collapsed core" can work just like the VC, doing both routing and switching, advantages being you now have
genuinely separate control planes, making future upgrades and maintenance a dream. It's a really good way to go.
Also, using IRBs is a good way to go, allowing maximum flexibility. 

As I always say, it's not the starting state that is difficult or the end state; it's the migration that is complex. 
where firewalls and dynamic routing protocols are involved, requires careful thought.
There is a lot of scope for traffic to head in directions you did not intend and to be blocked by the firewall. 

Is a big bang move from the SRX1 <> MX links possible? What outage are you permitted?

I might do something like this......

Build the EVPN core. 
Provision all the same VLANS ( VNIs in EVPN )
SPAN all the layer 2 between the MX10K <>  MX304 in a temporary link back-to-back link 
VRF Lite for any layer 3 over the same link ( typically firewalls in these scenarios are providing routing between VRFs ), just a guess here.  As I do not know your traffic flows. 
 

Links to the SRX will be tricky
Now you need to make a big decision: a big bang move on the SRX side ?
Or will you migrate services, VLANs, 1 by 1? The latter is more complex, but might be safer. 

I might provision a new AE between the SRX <> EVPN core.  But that needs careful consideration of metrics / stub areas  to prevent traffic from trying to route via the SRX. Policy would need a simple update; the new ae1 (let's call it ae11 ) would be added to all the same places.

Or a big bang might allow you no changes on the SRX side. 

I so wish engineers would set up /29s or /28s  on a irb on the  firewall links; it would make life so much easier for future engineers. allowing some more flexibility in migrations. There would be a 3rd strategy possible by spanning the ae1.100 between the MX10 and MX304s.
You could even think about converting your routed interfaces /30 to /28 irbs , which would tear down OSPF if I recall my theory correctly but cold be done with a few seconds outage. 

That's enough free consultancy. Obviously, this is quite non-specific without the detail available; This should paint a basic picture.  :-)




 



~

at high level, ae as L2 Active Active ESI, with IRB virtual GW, with EVPN-MPLS between MX304 should work

VGW and AA ESI will look as one device from SRX's view

irb would be .1 as VGW address, .2 and .3 on each MX304 as unique address. but looks like IP address is a concern, you may need at least /29 subnet for it