Topic: tech juniper jndf prev next
tech juniper jndf > 04: Organising the Data
Customer data comes from the following sources:
The customer requirements fall into the following groups:
The project boundaries are defined by:
Customer requirements typically fall into six groups (these are the same as collected above):
Budget underpins the other five groups.
Network Access Control (NAC) provides end to end security. An example is in SRX devices acting as 802.1X enforcers (EAP over wired networks).
Bring Your Own Device (BYOD) can be supported by Pulse Secure, a partner of Juniper Networks.
Archival and Backup requirements, including backups of config and data on the network devices. Junos Space can be used for log and configuration archiving. Capacity requirements include calculations for over-subscription and future growth.
The following constraints, and potentially others, define the design proposal boundaries;
Most network engineers will prefer greenfield, to brownfield, deployments. Brownfield deployments are much more common. Brownfield deployments often require integration with other vendors and proprietary protocols.
The customer may only allow certain groups to access certain applications. This might impose restrictions on the design. Users can be mapped to the applications they use.
The type of data flow on the network guides network design. Security and speed become more important as the network is opened up to WAN connections, for instance, remote offices and home users.
The three main functional parts are campus, branch offices, and data centre. Designing for these parts requires understanding user groups and applications, identifying existing wiring and media, and selecting the right devices.
A proposal should meet the customer’s requirements, but can go beyond the known boundaries and stated customer requirements. Provide multiple options in a proposal that match the customer’s needs.
Keep your design simple. Customers will equate a complicated design with a complicated, expensive and time consuming solution. Consider modularity in the design, as this will facilitate future growth and troubleshooting efforts.
Create the logical structure first, then the physical structure. Present both as diagrams to the customer. Consider a top-down design, rather than bottom-up. Bottom-up designs, which start with physical cabling, are usually made as fixes to specific problems. They are usually temporary, and fail to address the root cause of the problem.
Top-down design takes into account the customer requirements first, from the top of the OSI model (Application Layer) to the bottom.
Consider security at all stages of the design process. Analyse security risks, including from users and devices on the network. Identify network assets which must be secured. From these, determine security requirements and trade-offs.
Understand the design boundaries and scope, from the customer requirements. Remember that every choice made has a trade-off. For instance, implementing security might negatively impact performance, whilst changes to improve peformance might mean negatively impacting security. Or, lowering the cost by using slower WAN links will worsen the user experience.
Ensure that the proposal is clearly documented.
The design proposal should include plans to deal with current and future capacity. There are a number of ways to plan for capacity. Form a discussion group with stakeholders to understand the requirement. Quantify user behaviour and application behaviour.
Determine the baseline existing network, using packet traces, transaction rates, event logs and statistics. Identify ACL’s and firewall rules in use on the network. Make traffic projections, using current traffic statistics including bandwidth utilisation and congestion.
The design must be well documented. It acts as a benchmark for future design changes. The design document will not be ‘final’ for the lifetime of the network, and therefore should include a change history to aid maintenance.
The design document is used for the implementation of the network.