1. Status of the NA62 network R. Fantechi 23/5/2012

2. Cabling Fibers installed – Network fibers from rack J08 in PC room to racks EB36, STRAW1-02, RICH-02, IRC-01, GTK3-01, LAV3-01 – Clock fibers from EB20 to the above racks in ECN3 + to the PC room for the GTK – Patch panels for the above – Gigatracker fibers – Tested Missing, to be installed in the next 5 weeks – Patch cables (both clock and network) to connect the above “master” crates to the others – Patch cable from the PC room to the network starpoint in 918 This will be needed in the long term, together with a new cable from the starpoint to a nearby building to have the high speed link to the CDR Ordered, to be delivered in June – Patch cords to connect equipment to the fiber patch panels Including all the patches to connect the fibers in J08 to S08 where the cooled racks will be installed

3. Network equipment All the hardware available – HP8200 router with: Redundant power supplies 3 cards 8 10 Gb ports each 1 card with 24 1Gb copper ports, 4 of which can be optical – 7 HP2910 switches with 24 1 Gb copper ports Up to 2 10 Gb uplinks – The HP 2910 to be installed in EB36 (already done) STRAW1-02, LAV1-01, LAV2-01, LAV3-01, IRC-01, CEDAR Starpoint, to connect the structured cabling coming from the Control Room

4. Installation in 918 GTK fibers Network fibers Temporary HP 2910 Router Old NA48 network

5. Network addressing scheme We have got network 10.194.xxx.yyy – 65536 addresses – Too many? It could not be so simple…. IT/CS will configure the network in the proper way following CERN standards – Cern doesn’t use VLANs – Instead routed subnets Discussion about a flat network, only routed to GPN and TN But not safe, easily vulnerable from broadcast storms – Reminder: the actual layout is basically a central routing point with switches in the periphery to concentrate the traffic on 10 Gb links Apart from CREAM and L0 LKr switches (which don’t multiplex different type of traffic), in all the cases the traffic generated by the data themselves is well below 10 Gb/s In other words, when the data traffic is expected to be high, use dedicated switches

6. Proposal for the configuration Define “classes” of traffic – Data, DCS, configuration (CCPC + general services) Assign to each class on each switch a set of 32 or 64 addresses – Each triplet of sets is declared on one router port – The sets are routed towards the others – Events like broadcast storms are minimized They will affect only the end switch where they are generated – Complete logical separation of traffic on the different classes – No need to pre-assign switch ports to classes – In the limit of the address range, possibility to add a fan-out switch to increase the connectivity

7. Questions Define the structure in the next few weeks – Consider future needs as much as possible – Is it better to use 32 or 64 addresses per set? – Is 32 feasible? – Can we mix 32 and 64? – What about PCs directly connected to the router? – Useful to make test to validate TEL62-PC transfers across the router. Where? – For DCS compare this solution with the one with a complete separate DCS network – For the future, what about the Hexapus? – Configuring IGMP for IP multicast handling of LKr L1 requests – Given the abundance of network addresses, we can foresee for example 32 as a first maximum number of switches in the future

8. Possible scheme – Data Sw0 – Data Sw1 – … – Data Sw31 – Conf Sw0 – Conf Sw1 – … – Conf Sw31 – DCS Sw0 – DCS Sw1 – … – DCS Sw31 – CREAM Sw0 (32) – CREAM Sw1 (32) – … – CREAM Sw31 (32) – LKR L0 Sw0 (32) – LKR L0 Sw1 (32) – … – LKR L0 Sw5 (32) – PCFARM – PCFARM output (to CDR) – SLM readout PC (2012) (32) If not quoted, segmentation is 64