The following example shows how to configure the NetFlow Layer 2 and Security Monitoring Exports feature:
Router> enable
Router# configure terminal
Router(config)# ip flow-capture fragment-offset
Router(config)# ip flow-capture icmp
Router(config)# ip flow-capture ip-id
Router(config)# ip flow-capture mac-addresses
Router(config)# ip flow-capture packet-length
Router(config)# ip flow-capture ttl
Router(config)# ip flow-capture vlan-id
Router(config)# interface ethernet 0/0
Router(config-if)# ip flow ingress
or
Router(config-if)# ip flow egress
Router(config-if)# exit
Example: Analyzing a Simulated FTP Attack
The following example shows how to use the NetFlow Layer 2 and Security Monitoring Exports feature to find out whether your network is being attacked by a host that is sending fake FTP traffic in an attempt to overwhelm the FTP server. This attack might cause end users to see a degradation in the ability of the FTP server to accept new connections or to service existing connections.
Figure 7 shows a network in which Host A is sending fake FTP packets to the FTP server.
This example also shows you how to use the Layer 2 data, captured by the NetFlow Layer 2 and Security Monitoring Exports feature, to learn where the traffic is originating and what path it is taking through the network.
Figure 7. Test Network
Tip |
Track the MAC addresses and IP addresses of the devices in your network. You can use them to analyze attacks and resolve problems.
|
Note |
This example does not include the
ip
flow-capture
icmp command, which captures the value of the ICMP type and code fields.
|
R2
!
hostname R2
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc02
ip address 172.16.1.2 255.255.255.0
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc03
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 5
ip address 172.16.6.1 255.255.255.0
!
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
R3
!
hostname R3
!
ip flow-capture fragment-offset
ip flow-capture packet-length
ip flow-capture ttl
ip flow-capture vlan-id
ip flow-capture ip-id
ip flow-capture mac-addresses
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc04
no ip address
!
interface Ethernet0/0.1
encapsulation dot1Q 5
ip address 172.16.6.2 255.255.255.0
ip accounting output-packets
ip flow ingress
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc05
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 6
ip address 172.16.7.1 255.255.255.0
ip accounting output-packets
ip flow egress
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
R4
!
hostname R4
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc07
ip address 172.16.10.1 255.255.255.0
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc06
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 6
ip address 172.16.7.2 255.255.255.0
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
The
show
ip
cache
verbose
flow command displays the NetFlow flows that have been captured from the FTP traffic that Host A is sending.
The fields that have values captured by the
ip
flow-capture command are shown in Table 6. The fields and values are used to analyze the traffic for this example. The other fields captured by the
show
ip
cache
verbose
flow command are explained in subsequent tables (Table 7 to Table 9).
R3# show ip cache verbose flow
IP packet size distribution (3596 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .003 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .995 .000 .000 .000 .000 .000 .000 .000
The preceding output shows the percentage distribution of packets by size. In this display, 99.5 percent of the packets fall in the 1024-byte size range, and 0.3 percent fall in the 64-byte range.
The rest of the output of the
show
ip
cache
verbose
flow command is as follows:
IP Flow Switching Cache, 278544 bytes
5 active, 4091 inactive, 25 added
719 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 10 seconds
IP Sub Flow Cache, 25736 bytes
10 active, 1014 inactive, 64 added, 25 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-FTP 5 0.0 429 840 6.6 58.1 1.8
Total: 5 0.0 129 835 6.6 17.6 7.9
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
Et0/0.1 10.132.221.111 Et1/0.1 172.16.10.2 06 80 00 198
0015 /0 0 0015 /0 0 0.0.0.0 840 41.2
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 840 Max plen: 840
Min TTL: 59 Max TTL: 59
IP id: 0
Et0/0.1 10.251.138.218 Et1/0.1 172.16.10.2 06 80 00 198
0015 /0 0 0015 /0 0 0.0.0.0 840 41.2
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 840 Max plen: 840
Min TTL: 59 Max TTL: 59
IP id: 0
Et0/0.1 10.10.12.1 Et1/0.1 172.16.10.2 06 80 00 203
0015 /0 0 0015 /0 0 0.0.0.0 840 42.2
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 840 Max plen: 840
Min TTL: 59 Max TTL: 59
IP id: 0
Et0/0.1 10.231.185.254 Et1/0.1 172.16.10.2 06 80 00 203
0015 /0 0 0015 /0 0 0.0.0.0 840 42.2
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 840 Max plen: 840
Min TTL: 59 Max TTL: 59
IP id: 0
Et0/0.1 10.71.200.138 Et1/0.1 172.16.10.2 06 80 00 203
0015 /0 0 0015 /0 0 0.0.0.0 840 42.2
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 840 Max plen: 840
Min TTL: 59 Max TTL: 59
IP id: 0
R3#
Table 6 describes the significant fields shown in the NetFlow cache section of the output.
Table 6 Field Descriptions in the NetFlow Cache Section of the Output
Field
|
Description
|
bytes
|
Number of bytes of memory used by the NetFlow cache.
|
active
|
Number of active flows in the NetFlow cache at the time this command was entered.
|
inactive
|
Number of flow buffers that are allocated in the NetFlow cache but that were not assigned to a specific flow at the time this command was entered.
|
added
|
Number of flows created since the start of the summary period.
|
ager polls
|
Number of times the NetFlow code caused entries to expire (used by Cisco Customer Support Engineers (CSEs) for diagnostic purposes).
|
flow alloc failures
|
Number of times the NetFlow code tried to allocate a flow but could not.
|
last clearing of statistics
|
The period of time that has passed since the
clear
ip
flow
stats command was last executed. The standard time output format of hours, minutes, and seconds (hh:mm:ss) is used for a period of time less than 24 hours. This time output format changes to hours and days after the time exceeds 24 hours.
|
Table 7 describes the significant fields shown in the activity by the protocol section of the output.
Table 7 Field Descriptions in the Activity by Protocol Section of the Output
Field
|
Description
|
Protocol
|
IP protocol and the well-known port number. (Refer to
http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
Note
| Only a small subset of all protocols is displayed.
|
|
Total Flows
|
Number of flows for this protocol since the last time statistics were cleared.
|
Flows/Sec
|
Average number of flows for this protocol per second, which is equal to the total flows divided by the number of seconds for this summary period.
|
Packets/Flow
|
Average number of packets for the flows for this protocol, which is equal to the total packets for this protocol divided by the number of flows for this protocol for this summary period.
|
Bytes/Pkt
|
Average number of bytes for the packets for this protocol, which is equal to the total bytes for this protocol divided by the total number of packets for this protocol for this summary period.
|
Packets/Sec
|
Average number of packets for this protocol per second, which is equal to the total packets for this protocol divided by the total number of seconds for this summary period.
|
Active(Sec)/Flow
|
Number of seconds between the first and the last packet of an expired flow divided by the number of total flows for this protocol, for this summary period.
|
Idle(Sec)/Flow
|
Number of seconds observed from the last packet in each nonexpired flow for this protocol until the time at which the
show
ip
cache
verbose
flow command was entered divided by the total number of flows for this protocol, for this summary period.
|
Table 8 describes the significant fields in the NetFlow record section of the output.
Table 8 Field Descriptions in the NetFlow Record Section of the Output
Field
|
Description
|
SrcIf
|
Interface on which the packet was received.
|
Port Msk AS
|
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. This is always set to 0 in Multiprotocol Label Switching (MPLS) flows.
|
SrcIPaddress
|
The source IP address of the traffic in the five flows. The traffic is using five different IP source addresses. They are:
10.132.221.111
10.251.138.218
10.10.12.1
10.231.185.254
10.71.200.138
|
DstIf
|
Interface from which the packet was sent.
Note
| If an asterisk (*) immediately follows the DstIf field, the flow being shown is an egress flow.
|
|
Port Msk AS
|
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. The value of this field is always set to 0 in MPLS flows.
|
DstIPaddress
|
The destination IP address of the traffic.
Note
| 172.17.10.2 is the IP address of the FTP server.
|
|
NextHop
|
The Border Gateway Protocol (BGP) next-hop address. This is always set to 0 in MPLS flows.
|
Pr
|
IP protocol “well-known” port number, displayed in hexadecimal format. (Refer to
http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
|
ToS
|
Type of service, displayed in hexadecimal format.
|
B/Pk
|
Average number of bytes observed in the packets seen for this flow.
|
Flgs
|
TCP flag, shown in hexadecimal format. This value is the result of bitwise OR of the TCP flags from all packets in the flow.
|
Pkts
|
Number of packets in this flow.
|
Active
|
Time the flow has been active.
|
Table 9 describes the fields and values for the NetFlow Traffic Classification and Identification fields for the NetFlow record lines section of the output.
Table 9 NetFlow Traffic Classification and Identification Fields in the NetFlow Record lines section of the Output
Field
|
Description
|
MAC
|
The source and destination MAC addresses from the traffic, read from left to right in the output.
Note
| This MAC address is interface 1/0.1 on router R2.
|
Note
| This MAC address is interface 1/0.1 on router R4.
|
|
VLAN id
|
The source and destination VLAN IDs, read from left to right in the output.
|
Min plen
|
The minimum packet length for packets captured in the five flows.
The current value is 840.
|
Max plen
|
The maximum packet length for packets captured in the five flows.
The current value is 840.
|
Min TTL
|
The minimum time to live (TTL) for packets captured in the five flows.
The current value is 59.
|
Max TTL
|
The maximum TTL for packets captured in the five flows.
The current value is 59.
|
IP ID
|
The IP identifier field for the traffic in the five flows.
The current value is 0.
|
The fact that the Layer 3 TTL, identifier, and packet length fields in the five flows have the same values indicates that this traffic is a DoS attack. If this data had been captured from real traffic, the values would normally be different. The fact that all five of these flows have a TTL value of 59 indicates that this traffic is originating from points that are at the same distance from R3. Real user traffic would normally be arriving from different distances; therefore, the TTL values would be different.
If this traffic is identified as a DoS attack (based on the data captured in the Layer 3 fields), you can use the Layer 2 information in the flows to identify the path the traffic is taking through the network. In this example, the traffic is being sent to R3 on VLAN 5, by R2. You can demonstrate that R2 is transmitting the traffic over interface 1/0.1 because the source MAC address (aaaa.bbbb.cc03) belongs to 1/0.1 on R2. You can identify that R3 is transmitting the traffic using VLAN 6 on interface 1/0.1 to interface 1/0.1 on R4 because the destination MAC address (aaaa.bbbb.cc06) belongs to interface 1/0.1 on R4.
You can use this information to mitigate this attack. One possible way to mitigate this attack is to configure an extended IP access list that blocks FTP traffic from any host with a source address that is on the 10.0.0.0 network. Another possible solution is to configure a default route for the 10.0.0.0 network that points to the null interface on the router.
Caution |
Each of these solutions blocks traffic from legitimate hosts on the 10.0.0.0 network. Therefore these solutions should be used only while you identify the point of origin of the attack and decide how to stop it.
|
Example: Analyzing a Simulated ICMP Ping Attack
The following example shows how to use the NetFlow Layer 2 and Security Monitoring Exports feature to learn that your network is being attacked by ICMP traffic. It uses the network shown in Figure 7. Host A is sending very large ICMP ping packets to the FTP server.
R2
!
hostname R2
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc02
ip address 172.16.1.2 255.255.255.0
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc03
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 5
ip address 172.16.6.1 255.255.255.0
!
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
R3
!
hostname R3
!
ip flow-capture fragment-offset
ip flow-capture packet-length
ip flow-capture ttl
ip flow-capture vlan-id
ip flow-capture icmp
ip flow-capture ip-id
ip flow-capture mac-addresses
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc04
no ip address
!
interface Ethernet0/0.1
encapsulation dot1Q 5
ip address 172.16.6.2 255.255.255.0
ip accounting output-packets
ip flow ingress
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc05
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 6
ip address 172.16.7.1 255.255.255.0
ip accounting output-packets
ip flow egress
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
R4
!
hostname R4
!
interface Ethernet0/0
mac-address aaaa.bbbb.cc07
ip address 172.16.10.1 255.255.255.0
!
interface Ethernet1/0
mac-address aaaa.bbbb.cc06
no ip address
!
interface Ethernet1/0.1
encapsulation dot1Q 6
ip address 172.16.7.2 255.255.255.0
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
The
show
ip
cache
verbose
flow command displays the NetFlow flows that have been captured from the ICMP traffic that Host A is sending.
The fields that have their values captured by the
ip
flow-capture command are explained in Table 10. The fields and values are used to analyze the traffic for this example. The other fields captured by the
show
ip
cache
verbose
flow command are explained in the subsequent tables (Table 11 to Table 13).
R3# show ip cache verbose flow
IP packet size distribution (5344 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .166 .832 .000 .000 .000 .000 .000 .000
The preceding output shows the percentage distribution of packets by size. In this display, 16.6 percent of the packets fall in the 1024-byte size range and 83.2 percent fall in the 1536-byte range.
The rest of the output of the
show
ip
cache
verbose
flow command is as follows:
IP Flow Switching Cache, 278544 bytes
3 active, 4093 inactive, 7 added
91 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 10 seconds
IP Sub Flow Cache, 25736 bytes
7 active, 1017 inactive, 17 added, 7 added to flow
0 alloc failures, 0 force free
1 chunk, 0 chunks added
last clearing of statistics 00:01:13
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
ICMP 2 0.0 1500 1378 42.8 11.4 10.9
Total: 2 0.0 600 1378 42.9 11.5 10.8
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active
Et0/0.1 10.106.1.1 Et1/0.1 172.16.10.2 01 00 10 391
0000 /0 0 0800 /0 0 0.0.0.0 1500 8.6
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 1500 Max plen: 1500
Min TTL: 59 Max TTL: 59
ICMP type: 8 ICMP code: 0
IP id: 13499
Et0/0.1 10.106.1.1 Et1/0.1 172.16.10.2 01 00 00 1950
0000 /0 0 0000 /0 0 0.0.0.0 1354 8.6
MAC: (VLAN id) aaaa.bbbb.cc03 (005) aaaa.bbbb.cc06 (006)
Min plen: 772 Max plen: 1500
Min TTL: 59 Max TTL: 59
ICMP type: 0 ICMP code: 0
IP id: 13499 FO: 185
R3#
For field descriptions of the NetFlow Cache output, see Table 10.
Table 10 Field Descriptions in the NetFlow Cache Section of the Output
Field
|
Description
|
bytes
|
Number of bytes of memory used by the NetFlow cache.
|
active
|
Number of active flows in the NetFlow cache at the time this command was entered.
|
inactive
|
Number of flow buffers that are allocated in the NetFlow cache but that were not assigned to a specific flow at the time this command was entered.
|
added
|
Number of flows created since the start of the summary period.
|
ager polls
|
Number of times the NetFlow code caused entries to expire (used by Cisco Customer Support Engineers (CSEs) for diagnostic purposes).
|
flow alloc failures
|
Number of times the NetFlow code tried to but was not able to allocate flows.
|
last clearing of statistics
|
The period of time that has passed since the
clear
ip
flow
stats command was last executed. The standard time output format of hours, minutes, and seconds (hh:mm:ss) is used for a period of time less than 24 hours. The time output format changes to hours and days after the time exceeds 24 hours.
|
For field descriptions of the Activity by Protocol lines section of the output, see Table 11.
Table 11 Field Descriptions in the Activity by Protocol lines section of the Output
Field
|
Description
|
Protocol
|
IP protocol and the well-known port number. (Refer to
http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
Note
| Only a small subset of all protocols is displayed.
|
|
Total Flows
|
Number of flows for this protocol since the last time statistics were cleared.
|
Flows/Sec
|
Average number of flows for this protocol per second, which is equal to the total flows divided by the number of seconds for this summary period.
|
Packets/Flow
|
Average number of packets for the flows for this protocol, which is equal to the total packets for this protocol divided by the number of flows for this protocol for this summary period.
|
Bytes/Pkt
|
Average number of bytes for the packets for this protocol, which is equal to the total bytes for this protocol divided by the total number of packets for this protocol for this summary period.
|
Packets/Sec
|
Average number of packets for this protocol per second, which is equal to the total packets for this protocol divided by the total number of seconds for this summary period.
|
Active(Sec)/Flow
|
Number of seconds between the first and the last packet of an expired flow divided by the number of total flows for this protocol, for this summary period.
|
Idle(Sec)/Flow
|
Number of seconds observed from the last packet in each nonexpired flow for this protocol until the time at which the
show
ip
cache
verbose
flow command was entered, divided by the total number of flows for this protocol, for this summary period.
|
For field descriptions of the NetFlow Record lines section of the output, see Table 12.
Table 12 Field Descriptions in the NetFlow Record lines section of the Output
Field
|
Description
|
SrcIf
|
Interface on which the packet was received.
|
Port Msk AS
|
Source port number (displayed in hexadecimal format), IP address mask, and autonomous system number. The value of this field is always set to 0 in MPLS flows.
|
SrcIPaddress
|
IP address of the device that transmitted the packet. The sending host is using 10.106.1.1 as the source IP address.
|
DstIf
|
Interface from which the packet was sent.
Note
| If an asterisk (*) immediately follows the DstIf field, the flow being shown is an egress flow.
|
|
Port Msk AS
|
Destination port number (displayed in hexadecimal format), IP address mask, and autonomous system. This is always set to 0 in MPLS flows.
|
DstIPaddress
|
IP address of the destination device.
|
NextHop
|
The BGP next-hop address. This is always set to 0 in MPLS flows.
|
Pr
|
IP protocol “well-known” port number, displayed in hexadecimal format. (Refer to
http://www.iana.org, Protocol Assignment Number Services, for the latest RFC values.)
|
ToS
|
Type of service, displayed in hexadecimal format.
|
B/Pk
|
Average number of bytes observed for the packets seen for this flow.
|
Flgs
|
TCP flag, shown in hexadecimal format. This value is the result of bitwise OR of the TCP flags from all packets in the flow.
|
Pkts
|
Number of packets in this flow.
|
Active
|
Time the flow has been active.
|
For field descriptions of the NetFlow Traffic Classification and Identification fields, see Table 13.
Table 13 NetFlow Traffic Classification and Identification
Field
|
Description
|
MAC
|
The source and destination MAC addresses from the traffic, read from left to right in the output.
Note
| This MAC address is interface 1/0.1 on router R2.
|
Note
| This MAC address is interface 1/0.1 on router R4.
|
|
VLAN id
|
The source and destination VLAN IDs, read from left to right in the output.
|
Min plen
|
The minimum packet length for the packets captured in the two flows.
The current value for the first flow is 1500.
The current value for the second flow is 772.
|
Max plen
|
The maximum packet length for the packets captured in the two flows.
The current value for the first flow is 1500.
The current value for the second flow is 1500.
|
Min TTL
|
The minimum time to live (TTL) for the packets captured in the two flows.
The current value is 59.
|
Max TTL
|
The maximum TTL for the packets captured in the two flows.
The current value is 59.
|
IP
|
The IP identifier field for the traffic in the flows. The current value is 13499 for the two flows.
|
ICMP type
|
The Internet Control Message Protocol (ICMP) type field from the ICMP datagram captured in the first flow.
The value is 8.
|
ICMP code
|
The ICMP code field from the ICMP datagram captured in the second flow.
The value is 0.
|
FO
|
This is the value of the fragment offset field from the first fragmented datagram in the second flow.
The value is 185.
|
Two ICMP flows are shown in the output. They are from the same ICMP datagram because they have the same IP ID field value of 13499. When two ICMP flows have the same IP ID value, the ICMP datagram being analyzed has been fragmented. The first flow has the ICMP type field set to 8, which indicates that this is an ICMP echo request (ping) datagram. The value of 185 in the fragment offset (FO) field in the second flow shows where this fragment will be placed in the memory buffer of the FTP server as the server reassembles the ICMP datagram. The value of 185 applies only to the first fragment of this datagram. The subsequent values will be greater because they include the previous fragments.
The value of 0 in the ICMP type field of the second flow does not mean that this flow is an ICMP echo reply as Table 13 shows. In this case, the ICMP type field value is set to 0 because the ICMP headers for fragments of ICMP datagrams do not have the type and code fields. The default value of 0 is inserted instead.
Note |
If this data were captured from a real ICMP attack, it would probably have more than one flow.
|
Although you cannot learn the original size of the ICMP datagram from the information shown by the
show
ip
cache
verbose
flow command, the fact that the datagram was large enough to be fragmented in transit is a good indication that this is not a normal ICMP datagram. Notice the values in the minimum packet length and maximum packet length fields for both flows. The values for both fields are set to 1500 for the first flow. The value for the minimum packet length is set to 772 and the value for the maximum packet length is set to 1500 for the second flow.
If this traffic is identified as a DoS attack based on the data captured in the Layer 3 fields, you can use the Layer 2 information in the flows to identify the path that the traffic is taking through the network. In this example, the traffic is being sent to R3 on VLAN 5, by R2. Here, R2 is transmitting the traffic over interface 1/0.1 because the source MAC address (aaaa.bbb.cc03) belongs to 1/0.1 on R2. It is evident that R3 is transmitting the traffic using VLAN 6 on interface 1/0.1 to interface 1/0.1 on R4, because the destination MAC address (aaaa.bbbb.cc06) belongs to interface 1/0.1 on R4.
You can use this information to mitigate the attack. One possible way to mitigate this attack is by configuring an extended IP access list that blocks ICMP traffic from any host with a source address that is on the 10.0.0.0 network. Another possible solution is to configure a default route for the 10.0.0.0 network that points to the null interface on the router.
Caution |
Each of these solutions blocks traffic from legitimate hosts on the 10.0.0.0 network. Therefore, these solutions should be used only while you identify the point of origin of the attack and decide how to stop it.
|