1. Phare EIONET Centralised Training Session
EIONET node
Architecture & Connectivity

2. Overview of the Presentation
EIONET node components
Physical architecture
Logical architecture
Variations
IP Addressing issues
Additional servers
Management of the node
Questions & Comments

3. Eionet node components (standard architecture layout)
Internet link
Access server (router)
EIONET server(s)
Firewall
node’s LAN

4. Physical architecture
The only requirements from the point of view of physical connections are:
EIONET server should be connected to Internet
EIONET server should be connected to LAN
LAN should be connected to Internet.

5. Logical architecture
“The Internet” is able to access EIONET services
LAN should be able to access EIONET services + other services (ex. Mail retrieval)
Access to EIONET server(s) should comply to EIONET security policy
Access to LAN should comply to local security policy

6. Logical architecture (cont. …)
And that meens…
LAN topology and existing wiring style may may impose different solutions than the “standard” EIONET node schematics
Local security policy may require ALL computers to be “behind firewall”
Internet provider change may also change the interface to an unsupported one ...
Etc. ...
…we could need variations

7. Variations
Variations in EIONET node’s architecture are possible as long as they implement:
Physical connectivity constraints
Logical connectivity constraints
Compliance to EIONET security policy (applicable to EIONET server(s)
Invariance of the way OTHERS see and access your node’s services

8. Variations (cont. …) In punch-lines:
You should ensure the possibility of implementing two (usually) different security policies; eventually on the same machine …
You should be able to reliably distinguish between LAN users accessing EIONET server and Internet users
AGAIN and AGAIN: your structure should be functionally equal to all other EIONET nodes

9. Phare EIONET Centralised Training Session
Practical issues

10. large number of workstation in LAN
IP addressing scheme
When deciding the actual addressing scheme, each EIONET node faces one or more of the following constraints:
reduced number of registered IP addresses provided by ISP (a quarter of a C class or less)
large number of workstation in LAN
foreseeable growth in number of servers/workstations both in LAN and Internet exposed

11. Terms IP address; dotted decimal notation Network mask
Classfull and classless subneting
Subnet and Host ID
Subnetzero

12. IP network classes

13. Divide the available range of addresses

14. HW &. SW subnetting

15. Custom Subnetting: the steps

16. Chart for class C Networks

17. Determine subnet ID

18. Last step: Numbering Hosts

19. Additional servers
Physical and logical location of additional servers inside EIONET node structure should be decided studying:
Server audience (in terms of: LAN and/or Internet clients)
Server capabilities (in terms of protecting itself)
Impact to other servers and the node’s structure

20. Additional servers (cont. …)
Open Access
Reverse proxy, multi class segment, etc ...
EIONET security policy

21. Management of the node
There are several aspects of the node management:
System management: servers, routers, firewall(s); includes system backup/restore activity
Network management: connectivity, performance, network services
Application management: software installation, patches & upgrades; includes applications’ backup, data migration etc. ...
System, Network and Applications monitoring: logs, events etc.…
Security management: monitoring, updates, alarms, crisis scenarios preparation etc. ...

22. System management
Basic responsibilities for the EIONET node systems manager:
SO patches and upgrades: to be performed with balance between fixing bugs, enhancing functionality and keeping full compatibility with installed applications
Backup of vital system configuration data before any SO changes and/or reconfigurations are planned
Monitors event logs, disk and other resources usage and reacts accordingly to situations that may affect availability and/or quality of services offered by the respective systems
Keep users informed of changes, interrupts in operation and client side targeted security threats (I love you message …)

23. Network management General guidelines:
plan carefully structural changes; better still: avoid them
monitor network performance at all times, determine the bottleneck before users can feel it
if network complexity requires install automated SNMP tools to trap and alert you on unwanted events

24. Questions & Comments