Technical Description: Distribute bidirectional flows between client devices (GREEN, BLUE) and the server FARM. Each flow should be mapped to a different routing instance at GW, according to its TCP port, for application-specific treatment.
For this challenge, you need to start topology “GERMANY – Inter-instance flows”.
This challenge is aimed at developing a simple application-aware gateway (GW) configuration that allows bidirectional flow redirection between a server farm and different clients with simple Junos OS resources. Actually, GW is operating in packet mode, so think of the word “flow” as a set of packets with a common property (for example, IPs and TCP ports).
You are tasked to develop the simplest configuration on the GW device from the above described topology allowing end-to-end communication between local clients (devices GREEN and BLUE in this case) and a server farm (device FARM in this case), but segregating per-application flows into different links and routing instances between GW and FARM for deep inspection and analytical purposes.
Simple applications considered for this test are http (tcp:80 and tcp:8080), https (tcp:443), smtp (tcp:25) and access protocols like telnet (tcp:23) or ssh (tcp:22).
The challenge solution must be achieved under the following conditions:
- Communication must be bidirectional between clients and server
- All auxiliary routing instances between GW and FARM should carry segregated flows from the respective application in both directions.
- Configuration changes can only be carried out on GW, but you can use other devices for end-to-end testing and verification purposes:
juniper@BLUE> telnet 203.0.113.1 source 192.0.2.1 port 25
/* If communication is bidirectional, */
/* you get Connection refused message */
- You are not allowed to use rib-groups or static routes.
- You cannot apply any firewall filters to any interface.
- You can only define one single firewall filter in the configuration.
- 203.0.113.0/24 is considered as representative for the server farm (some loopback addresses from this range are configured in FARM for testing purposes), but neither this network nor its subnetworks must be referred (either directly or via prefix-list) in your added configuration
- Although there is no hard limit on the number of set configuration commands that you can apply in total, there is a specific limit at the [edit routing-instances] hierarchy level. You are only allowed to add a single set command to each routing instance, and this command must be the samefor all of them:
set routing-instances Access <same_command>
set routing-instances HTTP <same_command>
set routing-instances HTTPS <same_command>
set routing-instances SMTP <same_command>
CAUTION: The <same_command> string must NOT include the word “filter”. Otherwise you may cause a recursive lookup condition.
TIP: for downstream traffic, think of a certain Junos OS policy resource to import routes from the default instance.
To solve this challenge submit the changes needed according to the challenge’s conditions.