[INSTRM-163] Allocation of CIDRs for subsystems on the real network Created: 02/Aug/17  Updated: 22/Feb/18  Resolved: 22/Feb/18

Status: Done
Project: Instrument control development
Component/s: ics_dnsmasq
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: shimono Assignee: shimono
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks INSTRM-291 Provide development computer(s) at Su... Done
Sprint: 2017-10A

 Description   

Not linking to INSTRM-70, since this is a task for real allocation of resource.
We need to have definition and/or registration of allocation of subnets for subsystems at somewhere, as well as DHCP definitions in dnsmasq. So, we need to agree in this ticket on:

  • where (repository) and how (description file format) we will register allocations
  • registration management - will not change so much (it's subnet but not address)?
  • basic idea of allocation

Requirements (or desires?) of allocation criteria should be:

  • pack related subsystem in close subnet (e.g. xCU follows ENU), and in organized order (e.g. SM2 follows SM1)
  • allocate by one CIDR (to make thing simple) as much as possible, with slack in each subsystem
  • first address (.164.1) will be taken by default gateway (port at Subaru core switch), so we'd better to assign first CIDR to network switch subsystem

 Comments   
Comment by shimono [ 22/Aug/17 ]

repository to store this kind of definitions is better to be the same as configuration conventions, so let me propose the same directory of SSN-00028 with some reorganization (e.g. adding README.rst, have links from it).
https://github.com/Subaru-PFS/ics_doc/tree/master/SSN-00028

possible Idea for allocation:

  • .164.0/28 (.1-.15) network switches (core x1, CB2F x1, SpS x5+, Cs x1, PF x1, and?)
  • .164.16/28 (.16-.31) external services (ssh gateway etc.; has some slack for allocation)
  • .164.32/27 (.32-.63) infrastructure@CB2F (.32/28 for pysical, .48/28 for server)
  • .164.64/26 (.64-.127) SM1 (.64/28 for xCU, .96/28 for ENU+)
  • .164.128/26 (.128-.191) SM2 (.128/28 for xCU, .160/28 for ENU+)
  • .164.192/26 (.192-.255) SM3 (.192/28 for xCU, .224/28 for ENU+)
  • .165.0/26 (.0-.64) SM4 (.0/28 for xCU, .32/28 for ENU+)
  • .165.64/28 (.64-.79) PFI
  • .165.80/29 (.80-.87) Cs (MCS)
  • .165.192/27 (.192-.223) SCR control (devices, UPS)
  • .165.224/28 (.224-.239) SCR telemetry (temporary, development)
  • .165.240/28 (.240-.254) landfill

note:

  • need to have clearer idea for required number of addresses
  • is it better to pack 4 SMs into .165.0/24?
Comment by cloomis [ 26/Aug/17 ]

Do you forsee ever actually using IP subnets, each with a gateway and broadcast address? Or are you showing CIDR ranges just for allocation? If we know we will not be using routed subnets I'd prefer to allocate with decimal ranges, just for the sake of humans.

[ I think you mean /27 for the xCUs and ENUs: half of a /26, and 29-32 IP addresses ]

Comment by shimono [ 26/Aug/17 ]

sorry to make confusion, yes, it's CIDR, except for first and last.
also, half of /26 shall be /27.....

Comment by shimono [ 22/Sep/17 ]

added draft and PR as
https://github.com/Subaru-PFS/ics_doc/blob/tickets/INSTRM-163/SSN-00028/ipaddr.rst

Comment by shimono [ 28/Sep/17 ]

let me rename .164.64/27 as "CB2F ICS services and ICS infrastructure", to include basic services like dnsmasq or syslog etc. here.
I don't think we will have more than 16 hosts for ICS services, such as MHS, archive, SSC, etc, also more than 16 hosts for infrastructure, such as dnsmasq, syslog, elasticsearch, promehteus, etc.

also, keep in mind to assign first /28 for infrastructure, second /28 for services, as much as possible.

Comment by cloomis [ 07/Dec/17 ]

[ Moving to Review Complete does not open a comment panel, unlike some of the other transitions. ]

Since there will be no real routing the allocation does not strongly matter. So this is fine.

Comment by shimono [ 10/Dec/17 ]

cloomis could you change on github side also?

Comment by shimono [ 22/Feb/18 ]

merged

Generated at Sat Feb 10 16:22:11 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.