Firewall Filters on Logical Systems
Firewall filters provide rules that define to accept or discard packets that are transiting an interface. For more information, see the following topics:
Understanding How to Use Standard Firewall Filters
- Using Standard Firewall Filters to Affect Local Packets
- Using Standard Firewall Filters to Affect Data Packets
Using Standard Firewall Filters to Affect Local Packets
On a router, you can configure one physical loopback interface, lo0, and one or more addresses on the interface. The loopback interface is the interface to the Routing Engine, which runs and monitors all the control protocols. The loopback interface carries local packets only. Standard firewall filters applied to the loopback interface affect the local packets destined for or transmitted from the Routing Engine.
When you create an additional loopback interface, it is important to apply a filter to it so the Routing Engine is protected. We recommend that when you apply a filter to the loopback interface, you include the apply-groups statement. Doing so ensures that the filter is automatically inherited on every loopback interface, including lo0 and other loopback interfaces.
Trusted Sources
The typical use of a standard stateless firewall filter is to protect the Routing Engine processes and resources from malicious or untrusted packets. To protect the processes and resources owned by the Routing Engine, you can use a standard stateless firewall filter that specifies which protocols and services, or applications, are allowed to reach the Routing Engine. Applying this type of filter to the loopback interface ensures that the local packets are from a trusted source and protects the processes running on the Routing Engine from an external attack.
Flood Prevention
You can create standard stateless firewall filters that limit certain TCP and ICMP traffic destined for the Routing Engine. A router without this kind of protection is vulnerable to TCP and ICMP flood attacks, which are also called denial-of-service (DoS) attacks. For example:
A TCP flood attack of SYN packets initiating connection requests can overwhelm the device until it can no longer process legitimate connection requests, resulting in denial of service.
An ICMP flood can overload the device with so many echo requests (ping requests) that it expends all its resources responding and can no longer process valid network traffic, also resulting in denial of service.
Applying the appropriate firewall filters to the Routing Engine protects against these types of attacks.
Using Standard Firewall Filters to Affect Data Packets
Standard firewall filters that you apply to your router’s transit interfaces evaluate only the user data packets that transit the router from one interface directly to another as they are being forwarded from a source to a destination. To protect the network as a whole from unauthorized access and other threats at specific interfaces, you can apply firewall filters router transit interfaces .
See Also
Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
This example shows how to configure a stateless firewall filter that protects against ICMP denial-of-service attacks on a logical system.
Requirements
In this example, no special configuration beyond device initialization is required.
Overview
This example shows a stateless firewall filter called protect-RE that polices ICMP packets.
The icmp-policer
limits the traffic rate of the ICMP packets to 1,000,000 bps and
the burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded.
The policer is incorporated into the action of a filter term called icmp-term
.
In this example, a ping is sent from a directly connected physical router to the interface
configured on the logical system. The logical system accepts the ICMP packets if they are
received at a rate of up to 1 Mbps (bandwidth-limit). The logical system drops all ICMP packets
when this rate is exceeded. The burst-size-limit
statement accepts traffic bursts
up to 15 Kbps. If bursts exceed this limit, all packets are dropped. When the flow rate subsides,
ICMP packets are again accepted.
Topology
Figure 1 shows the topology used in this example.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste
them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit]
hierarchy level.
set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-policer set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30 set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-policer set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k set logical-systems LS1 firewall policer icmp-policer then discard
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Use the CLI Editor in Configuration Mode in the CLI User Guide.
To configure an ICMP firewall filter on a logical system:
Configure the interface on the logical system.
[edit] user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30
Explicitly enable ICMP packets to be received on the interface.
[edit] user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept
Create the policer.
[edit] user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k user@host# set logical-systems LS1 firewall policer icmp-policer then discard
Apply the policer to a filter term.
[edit] user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-policer
Apply the policer to the logical system interface.
[edit] user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-policer
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Results
Confirm your configuration by issuing the show logical-systems LS1
command.
user@host# show logical-systems LS1 interfaces { so-0/0/2 { unit 0 { family inet { policer { input icmp-policer; } address 10.0.45.2/30; } } } } firewall { family inet { filter protect-RE { term icmp-term { from { protocol icmp; } then { policer icmp-policer; accept; } } } } policer icmp-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } }
Verification
Confirm that the configuration is working properly.
Verifying That Ping Works Unless the Limits Are Exceeded
Purpose
Make sure that the logical system interface is protected against ICMP-based DoS attacks.
Action
Log in to a system that has connectivity to the logical system and run the ping
command.
user@R2> ping 10.0.45.2 PING 10.0.45.2 (10.0.45.2): 56 data bytes 64 bytes from 10.0.45.2: icmp_seq=0 ttl=64 time=1.316 ms 64 bytes from 10.0.45.2: icmp_seq=1 ttl=64 time=1.277 ms 64 bytes from 10.0.45.2: icmp_seq=2 ttl=64 time=1.269 ms
user@R2> ping 10.0.45.2 size 20000 PING 10.0.45.2 (10.0.45.2): 20000 data bytes ^C --- 10.0.45.2 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss
Meaning
When you send a normal ping, the packet is accepted. When you send a ping packet that exceeds the filter limit, the packet is discarded.
Example: Configuring Filter-Based Forwarding on Logical Systems
This example shows how to configure filter-based forwarding within a logical system. The filter classifies packets to determine their forwarding path within the ingress routing device.
Requirements
In this example, no special configuration beyond device initialization is required.
Overview
Filter-based forwarding is supported for IP version 4 (IPv4) and IP version 6 (IPv6).
Use filter-based forwarding for service provider selection when customers have Internet connectivity provided by different ISPs yet share a common access layer. When a shared media (such as a cable modem) is used, a mechanism on the common access layer looks at Layer 2 or Layer 3 addresses and distinguishes between customers. You can use filter-based forwarding when the common access layer is implemented using a combination of Layer 2 switches and a single router.
With filter-based forwarding, all packets received on an interface are considered. Each packet passes through a filter that has match conditions. If the match conditions are met for a filter and you have created a routing instance, filter-based forwarding is applied to a packet. The packet is forwarded based on the next hop specified in the routing instance. For static routes, the next hop can be a specific LSP.
Source-class usage filter matching and unicast reverse-path forwarding checks are not supported on an interface configured with filter-based forwarding (FBF).
To configure filter-based forwarding, perform the following tasks:
Create a match filter on an ingress router or switch. To specify a match filter, include the
filter filter-name
statement at the[edit firewall]
hierarchy level. A packet that passes through the filter is compared against a set of rules to classify it and to determine its membership in a set. Once classified, the packet is forwarded to a routing table specified in the accept action in the filter description language. The routing table then forwards the packet to the next hop that corresponds to the destination address entry in the table.Create routing instances that specify the routing table(s) to which a packet is forwarded, and the destination to which the packet is forwarded at the
[edit routing-instances]
or[edit logical-systems logical-system-name routing-instances]
hierarchy level. For example:[edit] routing-instances { routing-table-name1 { instance-type forwarding; routing-options { static { route 0.0.0.0/0 nexthop 10.0.0.1; } } } routing-table-name2 { instance-type forwarding; routing-options { static { route 0.0.0.0/0 nexthop 10.0.0.2; } } } }
Create a routing table group that adds interface routes to the forwarding routing instances used in filter-based forwarding (FBF), as well as to the default routing instance
inet.0
. This part of the configuration resolves the routes installed in the routing instances to directly connected next hops on that interface. Create the routing table group at the[edit routing-options]
or[edit logical-systems logical-system-name routing-options]
hierarchy level.
Specify inet.0
as one of the routing instances
that the interface routes are imported into. If the default instance inet.0
is not specified, interface routes are not imported
into the default routing instance.
This example shows a packet filter that directs customer traffic to a next-hop router in the domains, SP 1 or SP 2, based on the packet’s source address.
If the packet has a source address assigned to an SP 1 customer, destination-based forwarding occurs using the sp1-route-table.inet.0 routing table. If the packet has a source address assigned to an SP 2 customer, destination-based forwarding occurs using the sp2-route-table.inet.0 routing table. If a packet does not match either of these conditions, the filter accepts the packet, and destination-based forwarding occurs using the standard inet.0 routing table.
One way to make filter-based forwarding work within a logical system is to configure the firewall filter on the logical system that receives the packets. Another way is to configure the firewall filter on the main router and then reference the logical system in the firewall filter. This example uses the second approach. The specific routing instances are configured within the logical system. Because each routing instance has its own routing table, you have to reference the routing instances in the firewall filter, as well. The syntax looks as follows:
[edit firewall filter filter-name term term-name] user@host# set then logical-system logical-system-name routing-instance routing-instance-name
Topology
Figure 2 shows the topology used in this example.
On Logical System P1, an input filter classifies packets received from Logical System PE3 and Logical System PE4. The packets are routed based on the source addresses. Packets with source addresses in the 10.1.1.0/24 and 10.1.2.0/24 networks are routed to Logical System PE1. Packets with source addresses in the 10.2.1.0/24 and 10.2.2.0/24 networks are routed to Logical System PE2.
To establish connectivity, OSPF is configured on all of the interfaces. For demonstration purposes, loopback interface addresses are configured on the routing devices to represent networks in the clouds.
The CLI Quick Configuration section shows the entire configuration for all of the devices in the topology. The Configuring the Routing Instances on the Logical System P1 and Configuring the Firewall Filter on the Main Router sections shows the step-by-step configuration of the ingress routing device, Logical System P1.
Configuration
- CLI Quick Configuration
- Configuring the Firewall Filter on the Main Router
- Configuring the Routing Instances on the Logical System P1
- Results
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set firewall filter classify-customers term sp1-customers from source-address 10.1.1.0/24 set firewall filter classify-customers term sp1-customers from source-address 10.1.2.0/24 set firewall filter classify-customers term sp1-customers then log set firewall filter classify-customers term sp1-customers then logical-system P1 routing-instance sp1-route-table set firewall filter classify-customers term sp2-customers from source-address 10.2.1.0/24 set firewall filter classify-customers term sp2-customers from source-address 10.2.2.0/24 set firewall filter classify-customers term sp2-customers then log set firewall filter classify-customers term sp2-customers then logical-system P1 routing-instance sp2-route-table set firewall filter classify-customers term default then accept set logical-systems P1 interfaces lt-1/2/0 unit 10 encapsulation ethernet set logical-systems P1 interfaces lt-1/2/0 unit 10 peer-unit 9 set logical-systems P1 interfaces lt-1/2/0 unit 10 family inet filter input classify-customers set logical-systems P1 interfaces lt-1/2/0 unit 10 family inet address 172.16.0.10/30 set logical-systems P1 interfaces lt-1/2/0 unit 13 encapsulation ethernet set logical-systems P1 interfaces lt-1/2/0 unit 13 peer-unit 14 set logical-systems P1 interfaces lt-1/2/0 unit 13 family inet address 172.16.0.13/30 set logical-systems P1 interfaces lt-1/2/0 unit 17 encapsulation ethernet set logical-systems P1 interfaces lt-1/2/0 unit 17 peer-unit 18 set logical-systems P1 interfaces lt-1/2/0 unit 17 family inet address 172.16.0.17/30 set logical-systems P1 protocols ospf rib-group fbf-group set logical-systems P1 protocols ospf area 0.0.0.0 interface all set logical-systems P1 protocols ospf area 0.0.0.0 interface fxp0.0 disable set logical-systems P1 routing-instances sp1-route-table instance-type forwarding set logical-systems P1 routing-instances sp1-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.13 set logical-systems P1 routing-instances sp2-route-table instance-type forwarding set logical-systems P1 routing-instances sp2-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.17 set logical-systems P1 routing-options rib-groups fbf-group import-rib inet.0 set logical-systems P1 routing-options rib-groups fbf-group import-rib sp1-route-table.inet.0 set logical-systems P1 routing-options rib-groups fbf-group import-rib sp2-route-table.inet.0 set logical-systems P2 interfaces lt-1/2/0 unit 2 encapsulation ethernet set logical-systems P2 interfaces lt-1/2/0 unit 2 peer-unit 1 set logical-systems P2 interfaces lt-1/2/0 unit 2 family inet address 172.16.0.2/30 set logical-systems P2 interfaces lt-1/2/0 unit 6 encapsulation ethernet set logical-systems P2 interfaces lt-1/2/0 unit 6 peer-unit 5 set logical-systems P2 interfaces lt-1/2/0 unit 6 family inet address 172.16.0.6/30 set logical-systems P2 interfaces lt-1/2/0 unit 9 encapsulation ethernet set logical-systems P2 interfaces lt-1/2/0 unit 9 peer-unit 10 set logical-systems P2 interfaces lt-1/2/0 unit 9 family inet address 172.16.0.9/30 set logical-systems P2 protocols ospf area 0.0.0.0 interface all set logical-systems P2 protocols ospf area 0.0.0.0 interface fxp0.0 disable set logical-systems PE1 interfaces lt-1/2/0 unit 14 encapsulation ethernet set logical-systems PE1 interfaces lt-1/2/0 unit 14 peer-unit 13 set logical-systems PE1 interfaces lt-1/2/0 unit 14 family inet address 172.16.0.14/30 set logical-systems PE1 interfaces lo0 unit 3 family inet address 172.16.1.1/32 set logical-systems PE1 protocols ospf area 0.0.0.0 interface all set logical-systems PE1 protocols ospf area 0.0.0.0 interface fxp0.0 disable set logical-systems PE2 interfaces lt-1/2/0 unit 18 encapsulation ethernet set logical-systems PE2 interfaces lt-1/2/0 unit 18 peer-unit 17 set logical-systems PE2 interfaces lt-1/2/0 unit 18 family inet address 172.16.0.18/30 set logical-systems PE2 interfaces lo0 unit 4 family inet address 172.16.2.2/32 set logical-systems PE2 protocols ospf area 0.0.0.0 interface all set logical-systems PE2 protocols ospf area 0.0.0.0 interface fxp0.0 disable set logical-systems PE3 interfaces lt-1/2/0 unit 1 encapsulation ethernet set logical-systems PE3 interfaces lt-1/2/0 unit 1 peer-unit 2 set logical-systems PE3 interfaces lt-1/2/0 unit 1 family inet address 172.16.0.1/30 set logical-systems PE3 interfaces lo0 unit 1 family inet address 10.1.1.1/32 set logical-systems PE3 interfaces lo0 unit 1 family inet address 10.1.2.1/32 set logical-systems PE3 protocols ospf area 0.0.0.0 interface all set logical-systems PE3 protocols ospf area 0.0.0.0 interface fxp0.0 disable set logical-systems PE4 interfaces lt-1/2/0 unit 5 encapsulation ethernet set logical-systems PE4 interfaces lt-1/2/0 unit 5 peer-unit 6 set logical-systems PE4 interfaces lt-1/2/0 unit 5 family inet address 172.16.0.5/30 set logical-systems PE4 interfaces lo0 unit 2 family inet address 10.2.1.1/32 set logical-systems PE4 interfaces lo0 unit 2 family inet address 10.2.2.1/32 set logical-systems PE4 protocols ospf area 0.0.0.0 interface all set logical-systems PE4 protocols ospf area 0.0.0.0 interface fxp0.0 disable
Configuring the Firewall Filter on the Main Router
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure the firewall filter on the main router:
Configure the source addresses for SP1 customers.
[edit firewall filter classify-customers term sp1-customers] user@host# set from source-address 10.1.1.0/24 user@host# set from source-address 10.1.2.0/24
Configure the actions that are taken when packets are received with the specified source addresses.
To track the action of the firewall filter, a log action is configured. The sp1-route-table.inet.0 routing table on Logical System P1 routes the packets.
[edit firewall filter classify-customers term sp1-customers] user@host# set then log user@host# set then logical-system P1 routing-instance sp1-route-table
Configure the source addresses for SP2 customers.
[edit firewall filter classify-customers term sp2-customers] user@host# set from source-address 10.2.1.0/24 user@host# set from source-address 10.2.2.0/24
Configure the actions that are taken when packets are received with the specified source addresses.
To track the action of the firewall filter, a log action is configured. The sp2-route-table.inet.0 routing table on Logical System P1 routes the packet.
[edit firewall filter classify-customers term sp2-customers] user@host# set then log user@host# set then logical-system P1 routing-instance sp2-route-table
Configure the action to take when packets are received from any other source address.
All of these packets are simply accepted and routed using the default IPv4 unicast routing table, inet.0.
[edit firewall filter classify-customers term default] user@host# set then accept
Configuring the Routing Instances on the Logical System P1
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure the routing instances on a logical system:
Configure the interfaces on the logical system.
[edit logical-systems P1 interfaces lt-1/2/0] user@host# set unit 10 encapsulation ethernet user@host# set unit 10 peer-unit 9 user@host# set unit 10 family inet address 172.16.0.10/30 user@host# set unit 13 encapsulation ethernet user@host# set unit 13 peer-unit 14 user@host# set unit 13 family inet address 172.16.0.13/30 user@host# set unit 17 encapsulation ethernet user@host# set unit 17 peer-unit 18 user@host# set unit 17 family inet address 172.16.0.17/30
Assign the
classify-customers
firewall filter to router interface lt-1/2/0.10 as an input packet filter.[edit logical-systems P1 interfaces lt-1/2/0] user@host# set unit 10 family inet filter input classify-customers
Configure connectivity, using either a routing protocol or static routing.
As a best practice, disable routing on the management interface.
[edit logical-systems P1 protocols ospf area 0.0.0.0] user@host# set interface all user@host# set interface fxp0.0 disable
Create the routing instances.
These routing instances are referenced in the
classify-customers
firewall filter.The forwarding instance type provides support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance, in this case Logical System P1.
[edit logical-systems P1 routing-instances] user@host# set sp1-route-table instance-type forwarding user@host# set sp2-route-table instance-type forwarding
Resolve the routes installed in the routing instances to directly connected next hops.
[edit logical-systems P1 routing-instances] user@host# set sp1-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.13 user@host# set sp2-route-table routing-options static route 0.0.0.0/0 next-hop 172.16.0.17
Group together the routing tables to form a routing table group.
The first routing table, inet.0, is the primary routing table, and the additional routing tables are the secondary routing tables.
The primary routing table determines the address family of the routing table group, in this case IPv4.
[edit logical-systems P1 routing-options] user@host# set rib-groups fbf-group import-rib inet.0 user@host# set rib-groups fbf-group import-rib sp1-route-table.inet.0 user@host# set rib-groups fbf-group import-rib sp2-route-table.inet.0
Apply the routing table group to OSPF.
This causes the OSPF routes to be installed into all the routing tables in the group.
[edit logical-systems P1 protocols ospf] user@host# set rib-group fbf-group
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Results
Confirm your configuration by issuing the show
firewall
and show logical-systems P1
commands.
user@host# show firewall filter classify-customers { term sp1-customers { from { source-address { 10.1.1.0/24; 10.1.2.0/24; } } then { log; logical-system P1 routing-instance sp1-route-table; } } term sp2-customers { from { source-address { 10.2.1.0/24; 10.2.2.0/24; } } then { log; logical-system P1 routing-instance sp2-route-table; } } term default { then accept; } }
user@host# show logical-systems P1 interfaces { lt-1/2/0 { unit 10 { encapsulation ethernet; peer-unit 9; family inet { filter { input classify-customers; } address 172.16.0.10/30; } } unit 13 { encapsulation ethernet; peer-unit 14; family inet { address 172.16.0.13/30; } } unit 17 { encapsulation ethernet; peer-unit 18; family inet { address 172.16.0.17/30; } } } } protocols { ospf { rib-group fbf-group; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } } routing-instances { sp1-route-table { instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop 172.16.0.13; } } } sp2-route-table { instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop 172.16.0.17; } } } } routing-options { rib-groups { fbf-group { import-rib [ inet.0 sp1-route-table.inet.0 sp2-route-table.inet.0 ]; } } }
Verification
Confirm that the configuration is working properly.
Pinging with Specified Source Addresses
Purpose
Send some ICMP packets across the network to test the firewall filter.
Action
Log in to Logical System PE3.
user@host> set cli logical-system PE3 Logical system: PE3
Run the
ping
command, pinging the lo0.3 interface on Logical System PE1.The address configured on this interface is 172.16.1.1.
Specify the source address 10.1.2.1, which is the address configured on the lo0.1 interface on Logical System PE3.
user@host:PE3> ping 172.16.1.1 source 10.1.2.1 PING 172.16.1.1 (172.16.1.1): 56 data bytes 64 bytes from 172.16.1.1: icmp_seq=0 ttl=62 time=1.444 ms 64 bytes from 172.16.1.1: icmp_seq=1 ttl=62 time=2.094 ms ^C --- 172.16.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.444/1.769/2.094/0.325 ms
Log in to Logical System PE4.
user@host:PE3> set cli logical-system PE4 Logical system: PE4
Run the
ping
command, pinging the lo0.4 interface on Logical System PE2.The address configured on this interface is 172.16.2.2.
Specify the source address 10.2.1.1, which is the address configured on the lo0.2 interface on Logical System PE4.
user@host:PE4> ping 172.16.2.2 source 10.2.1.1 PING 172.16.2.2 (172.16.2.2): 56 data bytes 64 bytes from 172.16.2.2: icmp_seq=0 ttl=62 time=1.473 ms 64 bytes from 172.16.2.2: icmp_seq=1 ttl=62 time=1.407 ms ^C --- 172.16.2.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.407/1.440/1.473/0.033 ms
Meaning
Sending these pings activates the firewall filter actions.
Verifying the Firewall Filter
Purpose
Make sure the firewall filter actions take effect.
Action
Log in to Logical System P1.
user@host> set cli logical-system P1 Logical system: P1
Run the
show firewall log
command on Logical System P1.user@host:P1> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 13:52:20 pfe A lt-1/2/0.10 ICMP 10.2.1.1 172.16.2.2 13:52:19 pfe A lt-1/2/0.10 ICMP 10.2.1.1 172.16.2.2 13:51:53 pfe A lt-1/2/0.10 ICMP 10.1.2.1 172.16.1.1 13:51:52 pfe A lt-1/2/0.10 ICMP 10.1.2.1 172.16.1.1