SARAs routing update Pieter de Boer pietersara nl

SARA’s routing update Pieter de Boer (pieter@sara. nl) Senior Netwerkspecialist SARA Reken- en Netwerkdiensten

Agenda http: //www. this-page-intentionally-left-blank. org/ SARA Reken- en Netwerkdiensten 22 april 2009

How it all started Back in april 2007 (Munich) and january (Cambridge) description of our problem/setup Struggling to keep traffic flows seperate Researcher SARA Other host Storage cluster SARA Reken- en Netwerkdiensten SURFnet / GEANT lightpath services / LHCOPN SURFnet / GEANT routed IP CERN T 0 hosts 22 april 2009

We thought of PBR Ended up with VRF’s and the infamous out side loop Not very nice, but it did the job (until feb this year) Researcher SURFnet / GEANT lightpath network SURFnet routed IP SARA-R 1 Global CERN SARA-R 2 Global N P LHCO VRF Storage SARA Reken- en Netwerkdiensten 22 april 2009

VRF’s on a Juniper Lookup es rr Global Storag e clus Lofar ult fa LHCOPN ro Lo LH fa ou t N P O C De s ute Stor ter sta tic Storage cluster tatic er s t s u l c age SARA Reken- en Netwerkdiensten 22 april 2009

VRF’s on a Juniper continued Every OPN in it’s own VRF with static to the storage cluster Routes from a VRF exported with a tag Lookup VRF imports routes from the other VRF’s + add a default to the global Storage cluster does it’s route lookup in het lookup VRF Route lookup takes the most specific route out of a VRF and otherwise uses the default to the globel, in the global a sequentiel route lookup is performed, for the best rout there. SARA Reken- en Netwerkdiensten 22 april 2009

Researcher SURFnet / GEANT lightpath network SURFnet routed IP CERN SARA-R 2 Global SARA-R 1 Global LHCOPN Grid -R 1 Lookup Global Lofar SARA Reken- en Netwerkdiensten Storage cluster 22 april 2009

In short Every OPN in it’s own vrf Every OPN has a static to our storage cluster Routes from VRF exported into a loopup VRF, so our storage cluster sees them all, takes the most specific and defaults to the global after that Since no routes between OPN VRF’s are exchanged there is absolutely no risk of traffic leaking between OPN’s In addition the global doesn’t now anything of the OPN’s Same construction used for the perfsonar boxes, except they only see the LHCOPN and have the default option And it’s scaleable!!! SARA Reken- en Netwerkdiensten 22 april 2009

How we got here Wrote an extensive documents with requirements and send it to several vendors and asked them to come up with a proposal All proposals used either Cisco or Juniper (okay we where not really open to other vendors) Cisco tried the 6500/7600 route, but understood that wouldn’t work, they worked on a CRS-1 scenario but apparently couldn’t close the deal with that, or at least they didn’t submit a proposal. We also asked the vendors for a POC session, the one we had with Juniper was very usefull In the end our shortlist was between a MX and MX, from two different resellers with some minor differences. SARA Reken- en Netwerkdiensten 22 april 2009

Another use case We use a similar setup, but then with dynamic route leaking between the global and a VRF to work-a-round a issue with more specifics. We are working on a paper about our setup and will disseminate it in this group. SARA Reken- en Netwerkdiensten 22 april 2009

Questions? ? ? ? Or send me an e-mail pieter@sara. nl SARA Reken- en Netwerkdiensten 22 april 2009