Lab 4. Firewall Filters and Class of Service. Overview. Introduction to JUNOS Software & Routing Essentials

Transcription

1 Lab 4 Firewall Filters and Class of Service Overview This lab demonstrates configuration and monitoring of Firewall Filters and Class of Service on JUNOS devices. In this lab, you use the Command Line Interface (CLI) to configure and monitor firewall filters and class of service. In the first section of this lab (Part 1 2) you will prepare the lab devices for the firewall filter and class of service exercises. In the second part of the lab (Part 3) you will configure and monitor firewall filters. The third part (Parts 4 5) will continue from the firewall filters and refine the filters to be used in class of service to work as Multifield Classifiers to put identified traffic into correct forwarding class within the JUNOS device. All devices are connected to a common management network which facilitates access to the CLI. These exercises assume you already have some basic understanding of the JUNOS CLI interfaces or you have read the IJS documentation or similar. Note that your lab login (password given to you separately) grants you all permissions needed to complete this lab; however, some restrictions have been made to prevent loss of connectivity to the devices. Please be careful, and have fun! By completing this lab, you will perform the following tasks: Configure and verify proper operation of network interfaces. Configure and monitor firewall filters. Configure and monitor policers. Configure and monitor class of service. Please refer to the lab 4 diagram to perform Parts 1 5 of this lab exercise: 1

2 Lab Diagram 2

3 Key Commands Key operational mode commands used in this lab include the following: configure ping telnet show interfaces terse show interfaces queue show route show ospf neighbor show firewall Part 1: Configuring and Monitoring Interfaces In this lab part, you will configure network interfaces on your assigned devices. You will then verify that the interfaces are operational and display to corresponding route table entries. To do this Part you must configure the two devices that have been assigned to you (host1-x and host2-x). You need to configure both systems Note Please do NOT delete interface ge-0/0/0 as this is your management interface which provides access to your CLI session!! Do NOT delete either the security section of your configurations. This allows your system to allow any traffic in/out. Note 2 Preferably use the console connection to access your assigned devices. Using the console connection ensures persistent connectivity even when the management network access is unavailable. This lab could be done also via management interface. Note 3 Remember that the exercise proposed in this documentation is generic and the examples given here apply only to one particular pod of devices. Please adapt the example to your assigned set of devices (host1-a & host2-a, or host1-b & host2-b, or host1-c & host2-c, or host1-d & host2-d). Look at you lab diagram and mind the pod of systems that you have been assigned! 3

4 Step 1.1 Log in to the device using the console port with the username lab using the password given to you. Please use the console connection to access your system. ~]$ telnet Trying Connected to ( ). Escape character is '^]'. host1-a (ttyp2) login: lab Password: --- JUNOS 12.1R1.9 built :12:49 UTC Step 1.2 Issue the show route command to display the contents of the route table. You should see only the Direct and Local routes related to your device s management interface ge-0/0/0. lab@host1-a> show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /27 *[Direct/0] 2d 20:02:51 > via ge-0/0/ /32 *[Local/0] 2d 20:02:51 Local via ge-0/0/0.0 Step 1.3 Refer to the network diagram for this lab and configure the listed interfaces. Use logical unit 0 on the interfaces ge-0/0/1, ge-0/0/2 and ge-0/0/3, using a /30 as a subnet mask. Please observe that ge-0/0/4 is a tagged interface! Use the VLAN-ID as the logical unit value for the tagged interface. Wherever this lab example indicates 10v you will have to replace it with your system vlan-id (host1-b 10v=102). Use a mask of /24 for this interface. Please refer to the following table: VLAN Assignments (v=remainder of vlan-id) Hostname VLAN-ID host1-a 101 host2-a 102 4

5 host1-b 103 host2-b 104 host1-c 105 host2-c 106 host1-d 107 host2-d 108 At last, do not forget to configure the loopback interface with a logical unit 0 and subnet mask /32 [edit] lab@host1-a# edit interfaces [edit interfaces] lab@host1-a# set ge-0/0/1 unit 0 family inet address x/30 [edit interfaces] lab@host1-a# set ge-0/0/2 unit 0 family inet address x/30 [edit interfaces] lab@host1-a# set ge-0/0/3 unit 0 family inet address x.2/30 [edit interfaces] lab@host1-a# set lo0 unit 0 family inet address x.1/32 [edit interfaces] lab@host1-a# set ge-0/0/4 vlan-tagging [edit interfaces] lab@host1-a# set ge-0/0/4 unit 10v vlan-id 10v [edit interfaces] lab@host1-a# set ge-0/0/4 unit 10v family inet address v.1/24 Your configuration should look like the example below taken from host1-a. The following sample configuration is taken from host1-a in an environment using SRX Series devices. If your environment is using J Series devices, your output will be different. Please refer to the lab diagram given to you. [edit interfaces] lab@host1-a# show ge-0/0/0 { description "MGMT Interface - DO NOT DELETE"; unit 0 { family inet { address /27; 5

6 ge-0/0/1 { unit 0 { family inet { address /30; ge-0/0/2 { unit 0 { family inet { address /30; ge-0/0/3 { unit 0 { family inet { address /30; ge-0/0/4 { vlan-tagging; unit 101 { vlan-id 101; family inet { address /24; lo0 { unit 0 { family inet { address /32; Step 1.4 Activate the configuration and return to operational mode. [edit interfaces] lab@host1-a# commit and-quit commit complete Exiting configuration mode lab@host1-a> Note Please log into the other device assigned to you (host2-x) and repeat steps to complete the interface configuration! 6

7 Step 1.5 Issue the show interfaces terse CLI command to verify the state of the configured interfaces. show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0 up up ge-0/0/0.0 up up inet /27...TRIMMED... ge-0/0/1 up up ge-0/0/1.0 up up inet /30 ge-0/0/2 up up ge-0/0/2.0 up up inet /30 ge-0/0/3 up up ge-0/0/3.0 up up inet /30 ge-0/0/4 up up ge-0/0/4.101 up up inet /24 ge-0/0/ up up ge-0/0/5 up down ge-0/0/6 up down ge-0/0/7 up down ge-0/0/8 up down ge-0/0/9 up down ge-0/0/10 up down ge-0/0/11 up down ge-0/0/12 up down ge-0/0/13 up down ge-0/0/14 up down ge-0/0/15 up down gre up up ipip up up lo0 up up lo0.0 up up inet > 0/0...TRIMMED... What is the Admin and Link state of the recently configured interfaces? All configured interfaces should show an Admin and Link state of up, as shown in the sample capture. 7

8 Step 1.6 Once you have configured the other device (i.e. host2-x) use the ping utility to verify reachability to the neighbouring IPs connected to your device.. The following sample capture shows ping tests from host1-a to the Internet gateway, host2-a, and vr100, which are all directly connected: Were the pings to all directly connected neighbors successful? The output sample shows that you can successfully ping all directly connected neighbor interfaces ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=1.261 ms 64 bytes from : icmp_seq=1 ttl=64 time=1.153 ms 64 bytes from : icmp_seq=2 ttl=64 time=1.153 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.153/1.189/1.261/0.051 ms lab@host1-a> ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=1.235 ms 64 bytes from : icmp_seq=1 ttl=64 time=1.135 ms 64 bytes from : icmp_seq=2 ttl=64 time=1.180 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.135/1.183/1.235/0.041 ms lab@host1-a> ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=2.323 ms 64 bytes from : icmp_seq=1 ttl=64 time=3.618 ms 64 bytes from : icmp_seq=2 ttl=64 time=4.274 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.323/3.405/4.274/0.811 ms lab@host1-a> ping count 3 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=4.017 ms 64 bytes from : icmp_seq=1 ttl=64 time=8.165 ms 64 bytes from : icmp_seq=2 ttl=64 time=2.146 ms ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.146/4.776/8.165/2.515 ms lab@host1-a> 8

9 Step 1.7 Issue a show route command to confirm that your configured interfaces appear as Direct or Local in the routing table inet.0. lab@host1-a> show route inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both /27 *[Direct/0] 05:44:13 > via ge-0/0/ /32 *[Local/0] 05:44:13 Local via ge-0/0/ /30 *[Direct/0] 00:31:17 > via ge-0/0/ /32 *[Local/0] 00:31:17 Local via ge-0/0/ /30 *[Direct/0] 00:31:17 > via ge-0/0/ /32 *[Local/0] 00:31:17 Local via ge-0/0/ /30 *[Direct/0] 00:31:17 > via ge-0/0/ /32 *[Local/0] 00:31:17 Local via ge-0/0/ /24 *[Direct/0] 00:09:10 > via ge-0/0/ /32 *[Local/0] 00:09:10 Local via ge-0/0/ /32 *[Direct/0] 00:31:17 > via lo0.0 Does the route table display an entry for all local interface addresses and directly connected networks? Step 1.8 The answer should be yes. If needed, you can refer back to the network diagram and compare it with the displayed route entries. Using the console connection, enter configuration mode and navigate to the [edit system services] hierarchy level. Issue the show command to display the currently enabled services. lab@host1-a> configure Entering configuration mode [edit] lab@host1-a# edit system services 9

10 [edit system services] show ssh; telnet; [edit system services] Note The next lab steps require you to log in to the vr-device hosting the 8 virtual routers needed to simulate user hosts in this lab, one for each SRX device. The virtual routers are logical devices created on a Juniper J-Series Services Router. Refer to the management network diagram for the IP address of the vr-device. 10

11 Step 1.9 Open a separate SSH session to the Jump Server and from there a Telnet session to the vrdevice. Log in to the vr-device using the login information shown in the table here below. Virtual Router Login Details Student Device Username Password host1-a a1 lab123 host2-a a2 lab123 host1-b b1 lab123 host2-b b2 lab123 host1-c c1 lab123 host2-c c2 lab123 host1-d d1 lab123 host2-d d2 lab123 This example is from using the SRX-rack. Please refer always to your management network diagram, provided to you, for proper device addressing. [timo@js2 ~]$ telnet j2350 Trying Connected to j2350.lab2.cavellgroup.com ( ). Escape character is '^]'. vr-device (ttyp0) login: a1 Password: --- JUNOS 9.2R1.10 built :45:07 UTC NOTE: This router is divided into many virtual routers used by different stud ent teams. Your access is very limited to only the basic commands: show, clear and network commands. You cannot configure this router! Note The vr-device is separated into multiple virtual routing instances. The login user account you are using has only very limited authorization to certain operational mode commands. You cannot configure the vr-device. Keep the vrdevice session open, you will be using it repeatedly during the entire lab. 11

12 Step 1.10 From your assigned virtual router, use the ping utility to verify reachability to your device s loopback address and the Internet host. Refer to the network diagram associated with this lab as needed.. Note Remember to reference the appropriate instance name when sourcing ICMP traffic from a virtual router. The instance names match the virtual router names listed on the network diagram for this lab. 1a@vr-device> ping routing-instance vr count 3 rapid PING ( ): 56 data bytes!!! ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.640/1.830/1.928/0.134 ms Was the ping successful? The answer should be yes. Part 2: Configuring and Monitoring OSPF Step 2.1 In this part, you will configure and monitor OSPF. You will configure a single OSPF area based on the network diagram for this lab. Finally, you will perform some verification tasks to ensure that OSPF works properly. Enter configuration mode and define a router-id for your OSPF. The router-id should be set to your loopback address. Note In general you should not configure explicitly any router-id unless you want to change it to something different than the default (which is already the loopback). We are doing this in here to avoid commit errors that might result when attempting to commit a configuration that contains an ospf stanza and empty statements at the routing-options level. This behavior is extensively explained in KB20977 described in he Knowledge Base Juniper database. 12

13 configure Entering configuration mode [edit] set routing-options router-id Step 2.2 Define OSPF Area 0 and include all internal interfaces that connect to the remote device and the directly connected virtual router. Ensure that you also include the lo0 interface. Issue the show command to view the resulting configuration. Note Remember to specify the appropriate logical interface! If the logical unit is not specified, JUNOS Software assumes a logical unit of zero (0). Navigate to the [edit protocols ospf] hierarchy level and configure your interfaces [edit] lab@host1-a# edit protocols ospf [edit protocols ospf] lab@host1-a# set area interface ge-0/0/1.0 [edit protocols ospf] lab@host1-a# set area interface ge-0/0/2.0 [edit protocols ospf] lab@host1-a# set area interface ge-0/0/4.10v [edit protocols ospf] lab@host1-a# set area interface lo0.0 Your configuration should look similar to this example taken from host1-a: [edit protocols ospf] lab@host1-a# show area { interface ge-0/0/1.0; interface ge-0/0/2.0; interface ge-0/0/4.101; interface lo0.0; With the OSPF configuration in place, how many OSPF neighbour adjacencies should form? Although four interfaces are present in the configuration, only three of those interfaces 13

14 are capable of forming OSPF neighbour adjacencies. Before proceeding to the next section ensure you do a similar configuration in the other system assigned to you (host2-x). Step 2.3 Activate the candidate configuration using the commit command. Issue the run show ospf neighbour command to verify OSPF neighbour adjacency state information. Note The OSPF adjacency state with each neighbour is dependent on that neighbour s configuration. Ensure that the neighbouring system contains the required OSPF configuration and committed the changes. The virtual routers contain preconfigured settings. [edit protocols ospf] lab@host1-a# commit commit complete [edit protocols ospf] lab@host1-a# run show ospf neighbor Address Interface State ID Pri Dead ge-0/0/1.0 Full ge-0/0/2.0 Full ge-0/0/4.101 Full What state do the OSPF neighbour adjacencies show? Step 2.4 Although you might see some transitional states, the state for all three OSPF neighbours should eventually show Full. Issue the run show route protocol ospf to view the active OSPF routes in your device s route table. [edit protocols ospf] lab@host1-a# run show route protocol ospf inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 14

15 /24 *[OSPF/10] 00:00:44, metric 2 to via ge-0/0/1.0 > to via ge-0/0/ /32 *[OSPF/10] 00:01:32, metric 1 > to via ge-0/0/ /32 *[OSPF/10] 00:00:44, metric 1 > to via ge-0/0/1.0 to via ge-0/0/ /32 *[OSPF/10] 00:00:44, metric 2 > to via ge-0/0/1.0 to via ge-0/0/ /32 *[OSPF/10] 00:01:42, metric 1 MultiRecv Are all of the OSPF routes for the remote subnet and loopback destinations active? Why? Yes, as shown in output above. Step 2.5 From your assigned virtual router, use the ping utility to verify reachability to your lab POD s other virtual router s loopback address and the Internet host (similar to Step 1.9). Refer to the network diagram associated with this lab as needed, e.g. ping from vr100 lo0: to vr101 lo0: a@vr-device> ping routing-instance vr count 3 rapid PING ( ): 56 data bytes!!! ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.957/4.612/5.788/0.833 ms Note Remember to reference the appropriate instance name when sourcing ICMP traffic from a virtual router. The instance names match the virtual router names listed on the network diagram for this lab. Step 2.6 From your assigned virtual router, use the ping utility to verify reachability to your lab POD s SRXs loopback address. 15

16 ping routing-instance vr count 3 rapid PING ( ): 56 data bytes!!! ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.607/2.786/4.940/1.525 ms 1a@vr-device> ping routing-instance vr count 3 rapid PING ( ): 56 data bytes!!! ping statistics packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.985/2.218/2.594/0.268 ms Are the pings successful? The answer should be yes. If your ping fails please check your routing tables in both the vr-device and in the SRXs. Step 2.7 From your assigned virtual router, use the telnet utility to verify telnet service reachability to your lab POD s SRXs loopback address. 1a@vr-device> telnet routing-instance vr Trying Connected to Escape character is '^]'. host1-a (ttyp1) login: lab Password: --- JUNOS 12.1R1.9 built :12:49 UTC lab@host1-a> exit Connection closed by foreign host. 1a@vr-device> telnet routing-instance vr Trying Connected to Escape character is '^]'. host2-a (ttyp1) 16

17 login: lab Password: --- JUNOS 12.1R1.9 built :12:49 UTC exit Connection closed by foreign host. Are the telnet sessions successful? The answer should be yes. If your telnet fails please check that the telnet service is correctly configured in the SRXs. Part 3: Configuring and Monitoring Firewall Filters Step 3.1 In this part, you will configure and monitor firewall filters. You will configure two firewall filters, one for Telnet and the other for Ping (ICMP). You will be using the vr-device to generate traffic from and the SRX devices to either allow or deny the traffic. Log in to the host1-x device in your POD and enter configuration mode and navigate to the [edit firewall] hierarchy level. configure Entering configuration mode [edit] edit firewall [edit firewall] Step 3.2 Issue the edit family? command and answer the following questions. [edit firewall] edit family? Possible completions: 17

18 > any Protocol-independent filter > ccc Protocol family CCC for firewall filter > inet Protocol family IPv4 for firewall filter > inet6 Protocol family IPv6 for firewall filter > mpls Protocol family MPLS for firewall filter > vpls Protocol family VPLS for firewall filter [edit firewall] edit family Based on the available options, which family designation is used for IPv4 firewall filters? The family inet firewall filter option is used for IPv4 firewall filters. Step 3.3 Issue the edit family inet filter protect-host command in preparation to create a new IPv4 firewall filter named protect-host. [edit firewall] lab@host1-a# edit family inet filter protect-host [edit firewall family inet filter protect-host] lab@host1-a# Step 3.4 Create a term named limit-icmp1 that does not permit inbound ICMP packets to the /32 host. Create a term named limit-icmp2 that does not permit inbound ICMP packets to the /32 host if the utilized bandwidth exceeds 100 kbps and/or burst size exceeds 10 kbps. Bandwidth/burst utilization should be policed by a policer called police-icmp2. Create a term named limit-telnet that only permits inbound Telnet packets to the /32 host. Create a last term that accepts all other traffic. Remember a firewall filter has always the implicit discard as the last (invisible) term. [edit firewall family inet filter protect-host] lab@host1-a# show display set set firewall family inet filter protect-host term limit-icmp1 from destinationaddress /32 set firewall family inet filter protect-host term limit-icmp1 from protocol icmp 18

19 set firewall family inet filter protect-host term limit-icmp1 then count countlimit-icmp1 set firewall family inet filter protect-host term limit-icmp1 then discard set firewall family inet filter protect-host term limit-icmp2 from destinationaddress /32 set firewall family inet filter protect-host term limit-icmp2 from protocol icmp set firewall family inet filter protect-host term limit-icmp2 then policer policeicmp2 set firewall family inet filter protect-host term limit-icmp2 then count countlimit-icmp2 set firewall family inet filter protect-host term limit-telnet from destinationaddress /32 set firewall family inet filter protect-host term limit-telnet from protocol tcp set firewall family inet filter protect-host term limit-telnet from port 23 set firewall family inet filter protect-host term limit-telnet then count countlimit-telnet set firewall family inet filter protect-host term limit-telnet then discard set firewall family inet filter protect-host term accept-all then count countaccept-all set firewall family inet filter protect-host term accept-all then accept Step 3.5 You need to create the policer police-icmp2 under the [edit firewall] hierarchy. Issue command up 2 to move upwards in the configuration hierarchy. [edit firewall family inet filter protect-host] lab@host1-a# up 2 [edit firewall] lab@host1-a# show policer police-icmp2 display set set firewall policer police-icmp2 if-exceeding bandwidth-limit 100k set firewall policer police-icmp2 if-exceeding burst-size-limit 10k set firewall policer police-icmp2 then discard Step 3.6 Apply the firewall filter protect-host to interface ge-0/0/4.10v as an inbound filter to protect the 3 hosts from traffic initiated from the vr-device s routing instance connected to host1-x in your POD. [edit firewall] lab@host1-a# top edit interfaces ge-0/0/4 unit 101 [edit interfaces ge-0/0/4 unit 101] lab@host1-a# set family inet filter input protect-host 19

20 Step 3.7 Activate the configuration and return to operational mode. Issue the show firewall filter protect-host command to verify that the firewall filter is now active. [edit interfaces ge-0/0/4 unit 101] commit and-quit commit complete Exiting configuration mode show firewall filter protect-host Filter: protect-host Counters: Name Bytes Packets count-limit-icmp2 0 0 count-limit-icmp1 0 0 count-limit-telnet 0 0 count-accept-all Policers: Name Packets police-icmp2-limit-icmp2 0 Is the configured protect-host firewall filter active in your device? Yes, as illustrated in the sample output, the filter is active and the count-acceptall counter is counting up all other packets not being discarded by the protecthost filter. Step 3.8 Ping the loopback address of host1-x from the vr-device s routing instance connected to the host1-x device. 1a@vr-device> ping routing-instance vr count 3 rapid PING ( ): 56 data bytes ping statistics packets transmitted, 0 packets received, 100% packet loss 1a@vr-device> Is the ping successful? 20

21 No, as illustrated in the sample capture, the ping tests fails due the configured protect-host firewall filter. Step 3.9 Issue the show firewall filter protect-host counter count-limit-icmp1 command to verify that the counter count-limit-icmp1 is counting the discarded packets. show firewall filter protect-host counter count-limit-icmp1 Filter: protect-host Counters: Name Bytes Packets count-limit-icmp Has the counter value increased by the number of ICMP packets sent? Yes, as illustrated in the sample capture, the counter value has increased by 3 = number of ICMP packets sent. Step 3.10 Ping the loopback address of host2-x from the vr-device s routing instance connected to the host1- X device. Issue first 5 normal pings with no rapid option. Then issue 50 rapid pings with payload size 1500 bytes. 1a@vr-device> ping routing-instance vr count 5 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=63 time=2.809 ms 64 bytes from : icmp_seq=1 ttl=63 time=2.466 ms 64 bytes from : icmp_seq=2 ttl=63 time=2.518 ms 64 bytes from : icmp_seq=3 ttl=63 time=2.522 ms 64 bytes from : icmp_seq=4 ttl=63 time=4.214 ms ping statistics packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.466/2.906/4.214/0.665 ms 1a@vr-device> ping routing-instance vr count 50 rapid size 1500 PING ( ): 1500 data bytes!!!!!!.!!!.!!!.!!!.!!!.!!!!.!!!.!!!.!!!.!!!.!!!!.! ping statistics packets transmitted, 39 packets received, 22% packet loss round-trip min/avg/max/stddev = 2.735/7.363/ / ms 1a@vr-device> Is the first ping successful? Why? 21

22 Yes, as illustrated in the first 5 ICMP packets have been transmitted successfully. This because the total traffic volume does not exceed the bandwidth-limit nor the burst-size-limit configured in the police-icmp2 policer. What can you tell about the second ping? As illustrated in the second 50 ICMP packets have been partially transmitted. Total of 11 ICMP packets have been discarded by the configured rate policer. Step 3.11 Issue the show firewall filter protect-host command to verify that the counter countlimit-icmp2 and the policer police-icmp2 is counting the accepted (filter) and discarded (policer) packets. lab@host1-a> show firewall filter protect-host Filter: protect-host Counters: Name Bytes Packets count-limit-icmp count-limit-icmp count-limit-telnet 0 0 count-accept-all Policers: Name Packets police-icmp2-limit-icmp2 11 Has the counter value increased by the number of ICMP packets sent? Yes, as illustrated in the sample capture, the counter value of police-icmp2- limit-icmp2 has increased by 11 = number of ICMP packets discarded. Step 3.12 Telnet to the loopback address of host2-x from the vr-device s routing instance connected to the host1-x device. 1a@vr-device> telnet routing-instance vr Trying Connected to

23 Escape character is '^]'. host2-a (ttyp0) login: lab Password: --- JUNOS 12.1R1.9 built :12:49 UTC exit Connection closed by foreign host. Is the telnet successful? Yes, since the protect-host firewall filter does not discard telnet to Step 3.13 Telnet to the loopback address of vr-10v connected to your host2-x device. telnet routing-instance vr Trying ^C Is the telnet successful? No, as expected the protect-host firewall filter does not allow telnet to Step 3.14 Issue the show firewall filter protect-host counter count-limit-icmp2 command to verify that the counter count-limit-icmp2 is counting the discarded packets. show firewall filter protect-host counter count-limit-icmp2 Filter: protect-host Counters: Name Bytes Packets count-limit-icmp Has the counter value increased due the attempted telnet session? 23

24 Yes, as illustrated in the sample capture, the counter value has increased by 130 packets sent. Part 4: Class of Service In this part, you will configure class of service in both SRX devices. They will handle traffic from the vr-device connected to host1-x to the vr-device connected to host2-x according the class of service configuration. In host1-x you will modify the existing firewall filters to perform multi-field classification of ICMP and telnet traffic in order to apply the packets to forwarding classes accordingly plus configure the same device to mark packets sent to host2-x device. host2-x device will use BA classifiers to read ToS markings on received IP packets and apply the packets to forwarding classes accordingly. You will use the vr-device to generate ICMP and telnet traffic and then monitor the class of service function in both SRX devices. By default, JUNOS devices assign all traffic to the best-effort or network-control forwarding classes. Before you can assign traffic to other forwarding classes, you must configure a scheduler map for each interface with schedulers for those forwarding classes. In this part, you will associate queues with forwarding classes and configure schedulers and a scheduler map that you can apply to all interfaces. Use the following table to assist you in this part.: Forwarding Class Configuration Queue Forwarding Class BW & Buffer Allocation (%) Priority 0 best-effort 40 low 1 ICMP 45 medium-low 2 Telnet 10 high 3 network-control 5 medium-high Step 4.1 Enter configuration mode and navigate to the [edit class-of-service forwardingclasses] hierarchy level. Configure the forwarding class to queue mappings shown in the table. Configure this in both SRX devices. [edit] lab@host1-a# edit class-of-service forwarding-classes 24

25 [edit class-of-service forwarding-classes] set queue 1 ICMP [edit class-of-service forwarding-classes] lab@host1-a# set queue 2 Telnet Must you configure the best-effort and network-control forwarding classes or assign them to queues 0 and 3? No, it is not necessary because they are JUNOS default CoS forwarding classes / queues mapped together. Step 4.2 Configure a scheduler for each forwarding class using the parameters shown in the preceding table. Name the individual schedulers forwarding-class-name-sched, where the forwardingclass-name is the name of the scheduler s corresponding forwarding class. [edit class-of-service schedulers] lab@host1-a# show display set set class-of-service schedulers best-effort-sched transmit-rate percent 40 set class-of-service schedulers best-effort-sched buffer-size percent 40 set class-of-service schedulers best-effort-sched priority low set class-of-service schedulers ICMP-sched transmit-rate percent 45 set class-of-service schedulers ICMP-sched buffer-size percent 45 set class-of-service schedulers ICMP-sched priority medium-low set class-of-service schedulers Telnet-sched transmit-rate percent 10 set class-of-service schedulers Telnet-sched buffer-size percent 10 set class-of-service schedulers Telnet-sched priority high set class-of-service schedulers network-control-sched transmit-rate percent 5 set class-of-service schedulers network-control-sched buffer-size percent 5 set class-of-service schedulers network-control-sched priority medium-high Step 4.3 Configure a scheduler map named my-sched-map that associates each forwarding class with its corresponding scheduler. [edit class-of-service schedulers] lab@host1-a# up [edit class-of-service] lab@host1-a# edit scheduler-maps my-sched-map [edit class-of-service scheduler-maps my-sched-map] lab@host1-a# set forwarding-class best-effort scheduler best-effort-sched [edit class-of-service scheduler-maps my-sched-map] 25

26 set forwarding-class ICMP scheduler ICMP-sched [edit class-of-service scheduler-maps my-sched-map] set forwarding-class Telnet scheduler Telnet-sched [edit class-of-service scheduler-maps my-sched-map] set forwarding-class network-control scheduler network-control-sched [edit class-of-service scheduler-maps my-sched-map] Step 4.4 Step 4.5 Assign the scheduler map to the downstream interfaces in host1-x (ge-0/0/1 and ge-0/0/2) and host2-x (ge-0/0/4.10v). [edit class-of-service scheduler-maps my-sched-map] up 2 [edit class-of-service] lab@host1-a# edit interfaces [edit class-of-service interfaces] lab@host1-a# set ge-0/0/1 scheduler-map my-sched-map [edit class-of-service interfaces] lab@host1-a# set ge-0/0/2 scheduler-map my-sched-map [edit class-of-service interfaces] lab@host1-a# Modify the existing firewall filter protect-host to perform multi-field classification in host1-x device. You will perform the following changes: - Change the policer police-icmp2 to not to drop exceeding packets but to put them into Telnet forwarding-class. - Delete term limit-icmp1. - Modify term limit-icmp2 to put all ICMP packets within rate/burst limit into ICMP forwarding-class and the destination from /32 to 0/0 instead. - Modify term limit-telnet to put all telnet traffic to /32 into Telnet forwarding-class. Also remember to remove the discard statement under the then clause. - Remove the counters from the firewall filter s terms. Here below first an output of the current [edit firewall] configuration hierarchy and after that how it is supposed to be after your modifications. 26

27 [edit] show firewall policer police-icmp2 { if-exceeding { bandwidth-limit 100k; burst-size-limit 10k; then discard; family inet { filter protect-host { term limit-icmp1 { from { destination-address { /32; protocol icmp; then { count count-limit-icmp1; discard; term limit-icmp2 { from { destination-address { /32; protocol icmp; then { policer police-icmp2; count count-limit-icmp2; term limit-telnet { from { destination-address { /32; protocol tcp; port 23; then { count count-limit-telnet; discard; term accept-all { then { count count-accept-all; accept; 27

28 The modified configuration of host1-x. [edit] show firewall policer police-icmp2 { if-exceeding { bandwidth-limit 100k; burst-size-limit 10k; then forwarding-class Telnet; family inet { filter protect-host { term limit-icmp2 { from { destination-address { /0; protocol icmp; then { policer police-icmp2; forwarding-class ICMP; term limit-telnet { from { destination-address { /32; protocol tcp; port 23; then forwarding-class Telnet; term accept-all { then { count count-accept-all; accept; Step 4.6 Since the firewall filter protect-host was modified, there is no need to apply it on host1-x s ge- 0/0/4 interface. It is already configured there as an input firewall filter. 28

29 Now you will generate some ICMP and Telnet traffic from vr-device to ensure that it is being placed in the correct forwarding classes. First check the output of commands show interfaces queue ge-0/0/1 and show interfaces queue ge-0/0/2 to make sure the queues 1 and 2 are visible and that the counters are still showing zero packets. lab@host1-a> show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex: 120 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort High : 0 0 bps Queue: 1, Forwarding classes: ICMP Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 2, Forwarding classes: Telnet Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 3, Forwarding classes: network-control High : 0 0 bps lab@host1-a> 29

30 Step 4.7 Use the ping utility to ping the other vr-device routing instance lo= IP address. ping routing-instance vr count 5 PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=62 time=7.441 ms 64 bytes from : icmp_seq=1 ttl=62 time=3.600 ms 64 bytes from : icmp_seq=2 ttl=62 time=4.495 ms 64 bytes from : icmp_seq=3 ttl=62 time=6.043 ms 64 bytes from : icmp_seq=4 ttl=62 time=5.284 ms ping statistics packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.600/5.373/7.441/1.315 ms 1a@vr-device> Did the ping test succeed? Step 4.8 The answer should be yes. As displayed in the sample capture, the ping test to succeeds. Check the queues again to see if the ICMP packets were put into the ICMP forwarding-class. lab@host1-a> show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex: 120 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 5 0 pps Bytes : bps Transmitted: Packets : 5 0 pps Bytes : bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps 30

31 Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : Have the ICMP packets been put into correct forwarding class? Yes, as shown in the output 5 packets have been put into the ICMP forwardingclass. Step 4.9 Use the telnet utility to connect to the other vr-device routing instance lo= IP address. 1a@vr-device> telnet routing-instance vr Trying Connected to Escape character is '^]'. vr-device (ttyp1) login: 1b Password: --- JUNOS 9.2R1.10 built :45:07 UTC NOTE: This router is divided into many virtual routers used by different student teams. Your access is very limited to only the basic commands: show, clear and network commands. You cannot configure this router! 1b@vr-device> exit Connection closed by foreign host. 1a@vr-device> Did the telnet tests succeed? 31

32 Step 4.10 The answer should be yes. As displayed in the sample capture, the telnet test to succeeds. Check the queues again to see if the Telnet packets were put into the Telnet forwarding-class. show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex: 120 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 2, Forwarding classes: Telnet Queued: Packets : 48 0 pps Bytes : bps Transmitted: Packets : 48 0 pps Bytes : bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Have the Telnet packets been put into correct forwarding class? Yes, as shown in the output 48 packets have been put into the Telnet forwarding-class. Step 4.11 Now, let s check the queues in host2-x interface ge-0/0/4 facing the pinged/telneted vr-device s routing instance. lab@host2-a> show interfaces queue ge-0/0/4 32

33 Physical interface: ge-0/0/4, Enabled, Physical link is Up Interface index: 135, SNMP ifindex: 129 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 2, Forwarding classes: Telnet Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 3, Forwarding classes: network-control lab@host2-a> Have the ICMP and Telnet packets been put into correct forwarding class? No, as shown in the output forwarding-classes ICMP and Telnet show zero packet 33

34 count. Why are the counters showing zero? Class of service is configured in host2-x, right? Class of service is configured, but packets received from host1-x are being treated just as normal best-effort packets since there is no multifield-classifier configured as in host1-x (which should not be configured in host2-x). Instead of multifieldclassifier you should configure BA (Behaviour Aggregation) rewrite marking in host1-x for the outbound packets and (BA) classifiers in host2-x inbound interface. This will be the final task of your class of service configuration. Part 5: Configuring BA and Rewrite Rules and Classifiers Step 5.1 In this lab part, you will configure the host1-x to rewrite a BA marker based on the forwarding class. You will then configure host2-x to classify incoming traffic based on BA markings. Finally you will verify your configuration by generating traffic from one vr-device routing instance to another, just like you did in Steps Enter configuration mode and navigate to the [edit class-of-service] hierarchy level in host1-x. lab@host1-a> configure Entering configuration mode [edit] lab@host1-a# edit class-of-service [edit class-of-service] lab@host1-a# Step 5.2 Configure interfaces ge-0/0/1 and ge-0/0/2 to use the default IP precedence rewrite rule for the outbound traffic. Do not forget to commit your changes! [edit class-of-service] lab@host1-a# set interfaces ge-0/0/1 unit 0 rewrite-rules inet-precedence default [edit class-of-service] lab@host1-a# set interfaces ge-0/0/2 unit 0 rewrite-rules inet-precedence default [edit class-of-service] 34

35 commit and-quit commit complete Exiting configuration mode Step 5.3 Enter configuration mode and navigate to the [edit class-of-service] hierarchy level in host2-x. configure Entering configuration mode [edit] edit class-of-service [edit class-of-service] Step 5.4 Configure interfaces ge-0/0/1 and ge-0/0/2 to use the default IP precedence classifier for the inbound traffic. Do not forget to commit your changes! [edit class-of-service] set interfaces ge-0/0/1 unit 0 classifiers inet-precedence default [edit class-of-service] lab@host2-a# set interfaces ge-0/0/2 unit 0 classifiers inet-precedence default [edit class-of-service] lab@host2-a# commit and-quit commit complete Exiting configuration mode lab@host2-a> Step 5.5 Clear all statistics on host1-x interfaces ge-0/0/1 and ge-0/0/2. Check that the queues are showing zero values. lab@host1-a> clear interfaces statistics ge-0/0/1 lab@host1-a> clear interfaces statistics ge-0/0/2 lab@host1-a> show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex:

36 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 2, Forwarding classes: Telnet Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 3, Forwarding classes: network-control lab@host1-a> show interfaces queue ge-0/0/2 Physical interface: ge-0/0/2, Enabled, Physical link is Up Interface index: 133, SNMP ifindex: 127 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: 36

37 Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 2, Forwarding classes: Telnet Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps Queue: 3, Forwarding classes: network-control lab@host1-a> Are the queues cleared to zero values? Step 5.6 Yes, as shown in the output all queues were cleared. Queues 0 and 3 are showing values higher than zero since they are forwarding network-control and best-effort traffic as defined by the devices default behaviour. Use the ping utility to ping the other vr-device routing instance lo= IP address. 1a@vr-device> ping routing-instance vr count 5 PING ( ): 56 data bytes 37

38 64 bytes from : icmp_seq=0 ttl=62 time= ms 64 bytes from : icmp_seq=1 ttl=62 time= ms 64 bytes from : icmp_seq=2 ttl=62 time= ms 64 bytes from : icmp_seq=3 ttl=62 time= ms 64 bytes from : icmp_seq=4 ttl=62 time= ms ping statistics packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = /97.617/99.070/0.896 ms 1a@vr-device> Did the ping test succeed? Step 5.7 The answer should be yes. As displayed in the sample capture, the ping test to succeeds. Check the queues in host1-x (ge-0/0/1 and ge-0/0/2) and host2-x (ge-0/0/4) to see if the ICMP packets were put into the ICMP forwarding-class. lab@host1-a> show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex: 120 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 5 0 pps Bytes : bps Transmitted: Packets : 5 0 pps Bytes : bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps 38

39 show interfaces queue ge-0/0/4 Physical interface: ge-0/0/4, Enabled, Physical link is Up Interface index: 135, SNMP ifindex: 129 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queue: 1, Forwarding classes: ICMP Queued: Packets : 5 0 pps Bytes : bps Transmitted: Packets : 5 0 pps Bytes : bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps lab@host2-a> Have the ICMP packets been put into correct forwarding class? Yes, as shown in the output 5 packets have been put into the ICMP forwardingclass in both SRXs. Why is the byte count larger in host2-x s ge-0/0/4 interface? Byte count is 20 bytes larger. Remeber the ge-0/0/1 and ge-0/0/2 are configured to normal Ethernet while the ge-0/0/4 is 802.1Q tagged, thus having 4 extra bytes per packet. 39

40 Step 5.8 Use the telnet utility to connect to the other vr-device routing instance lo= IP address. telnet routing-instance vr Trying Connected to Escape character is '^]'. vr-device (ttyp3) login: 1b Password: --- JUNOS 9.2R1.10 built :45:07 UTC NOTE: This router is divided into many virtual routers used by different student teams. Your access is very limited to only the basic commands: show, clear and network commands. You cannot configure this router! exit Connection closed by foreign host. Did the telnet tests succeed? The answer should be yes. As displayed in the sample capture, the telnet test to succeeds. Step 5.9 Check the queues in host1-x (ge-0/0/1 and ge-0/0/2) and host2-x (ge-0/0/4) to see if the Telnet packets were put into the Telnet forwarding-class. show interfaces queue ge-0/0/1 Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 132, SNMP ifindex: 120 Forwarding classes: 8 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort : 0 0 bps 40