- Documentation
- Prerequisite
- Scenario One
- Topology
- Problem Description
- Steps
- Commands to enable packet tracer
- Conditions to capture data
- Specify what packets to trace
- Start the condition
- See the packets captured
- Save the data
- Cleanup
- Scenario Two
- Topology
- Problem Description
- Steps
- Commands to enable packet tracer
- Conditions to capture data
- Specify what packets to trace
- Start the condition
- See the packets captured
- Cleanup
Documentation
This configuration example is meant to be interpreted with the aid of the official documentation from the configuration guide located here: https://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/Packet_Trace.html
Prerequisite
The ASR must be running minimum XE 3.10 code to be able to use this feature. Cisco IOS-XE Software Release 3.10S (15.3(3)S) and later has this capability.
Scenario One
Topology
Problem Description
Neither Employee 1 or Employee 2 is able to go load social media, streaming or gaming websites.
Steps
Using packet trace is very straightforward. All you need to do is:
1. Write the condition for which you would like to gather the data
2. Specify what packets to capture and how many
3. Start, run the test and stop the condition
4. Save the data
5. Cleanup
Commands to enable packet tracer
Conditions to capture data
Configure the interesting ACL ip access-list extended debug 10 permit ip host 192.168.101.2 any 20 permit ip any host 192.168.101.2 Define the conditional debug/packet capture settings using the ACL from above: debug platform condition ipv4 access-list debug both
[OR]
debug platform condition interface g0/0/0 ipv4 access-list debug both
These two lines are to troubleshoot firewall debug platform condition feature fw dataplane submode policy drop layer4 event level verbose debug platform condition feature fw dataplane submode all level verbose
These two lines are to troubleshoot Snort IPS
debug platform condition feature utd data sub all level verbose
debug platform condition feature service-divert dataplane submode all level verbose
Specify what packets to trace
debug platform packet-trace packet 256 circular fia-trace debug platform packet-trace copy packet both l2
debug platform packet-trace drop
Start the condition
Start the capture, test the broken flow and then stop the capture.
Begin the packet capture: debug platform condition start Run the problematic traffic for a few seconds Then stop the packet capture: debug platform condition stop
See the packets captured
kusankar-1121X#show platform packet-trace summary | i DROP
0 Gi0/1/0 Gi0/0/0 DROP 189 (FirewallL7)
3 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
4 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
5 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
6 Gi0/1/0 Gi0/0/0 DROP 189 (FirewallL7)
7 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
8 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
9 Gi0/1/0 Gi0/0/0 DROP 189 (FirewallL7)
10 Gi0/1/0 Vl101 DROP 215 (UnconfiguredIpv4Fia)
.... many more drops is seen...
Now let us try to see why packet 0 was dropped. The output is rather exhaustive but let us just scroll through and see what in the world is going on...
kusankar-1121X#shwo platform packet-trace packet 0
Packet: 0 CBUG ID: 62803
Summary
Input : GigabitEthernet0/1/0
Output : GigabitEthernet0/0/0
State : DROP 189 (FirewallL7)
Timestamp
Start : 130004634161440 ns (06/04/2022 15:58:25.804986 UTC)
Stop : 130004634758360 ns (06/04/2022 15:58:25.805583 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet0/1/0
Output : <unknown>
Source : 192.168.101.2
Destination : 4.2.2.2
Protocol : 17 (UDP)
SrcPort : 55952
DstPort : 53 ================> DNS packet
Feature: DEBUG_COND_INPUT_PKT
Entry : Input - 0x113f876c
Input : GigabitEthernet0/1/0
Output : <unknown>
Lapsed time : 600 ns
Feature: L2_ES_INPUT_CONTROL_CHECK
Entry : Input - 0x114174c0
Input : GigabitEthernet0/1/0
Output : <unknown>
Lapsed time : 2640 ns
Feature: L2_INPUT_SVI_LOOKUP
Entry : Input - 0x114174c8
Input : Vlan101
Output : <unknown>
Lapsed time : 2960 ns
Feature: CBUG_INPUT_FIA
Entry : Input - 0x113f8750
Input : Vlan101
Output : <unknown>
Lapsed time : 280 ns
Feature: DEBUG_COND_INPUT_PKT
Entry : Input - 0x113f876c
Input : Vlan101
Output : <unknown>
Lapsed time : 320 ns
Feature: IPV4_INPUT_DST_LOOKUP_ISSUE
Entry : Input - 0x114165fc
Input : Vlan101
Output : <unknown>
Lapsed time : 1160 ns
Feature: IPV4_INPUT_ARL_SANITY
Entry : Input - 0x113fa370
Input : Vlan101
Output : <unknown>
Lapsed time : 2080 ns
Feature: IPV4_INPUT_DST_LOOKUP_CONSUME
Entry : Input - 0x114165f8
Input : Vlan101
Output : <unknown>
Lapsed time : 760 ns
Feature: IPV4_INPUT_FOR_US_MARTIAN
Entry : Input - 0x11416604
Input : Vlan101
Output : <unknown>
Lapsed time : 560 ns
Feature: CFT
API : cft_handle_pkt
packet capabilities : 0x0000018c
input vrf_idx : 0
calling feature : STILE
direction : Input
triplet.vrf_idx : 0
triplet.network_start : 0x01003f92
triplet.triplet_flags : 0x00000000
triplet.counter : 129
cft_bucket_number : 56692
cft_l3_payload_size : 38
cft_pkt_ind_flags : 0x00000203
cft_pkt_ind_valid : 0x0000dbff
tuple.src_ip : 192.168.101.2
tuple.dst_ip : 4.2.2.2
tuple.src_port : 55952
tuple.dst_port : 53
tuple.vrfid : 0
tuple.l4_protocol : UDP
tuple.l3_protocol : IPV4
vrf_nums : 1
pkt_sb.num_flows : 1
pkt_sb.tuple_epoch : 129
returned cft_error : 0
returned fid : 0x41d31dc0
Feature: NBAR
Packet number in flow: 1
Classification state: Final
Classification name: facebook
Classification ID: 1454 [CANA-L7:518]
Candidate classification sources:
DPI: facebook [1454]
L3-Cache: dns [72]
Classification visibility name: facebook
Classification visibility ID: 1454 [CANA-L7:518]
Number of matched sub-classifications: 0
Number of extracted fields: 0
Is PA (split) packet: False
TPH-MQC bitmask value: 0x8
Source MAC address: 60:EB:69:51:3B:3A
Destination MAC address: 00:B7:71:B6:65:F4
Traffic Categories:
ms-office-365/category: unset
ms-office-365/service-area: unset
sdavc/feed-id: 0
Feature: IPV4_INPUT_STILE_LEGACY
Entry : Input - 0x113e40fc
Input : Vlan101
Output : <unknown>
Lapsed time : 201720 ns
Feature: DEBUG_COND_APPLICATION_IN
Entry : Input - 0x113f875c
Input : Vlan101
Output : <unknown>
Lapsed time : 160 ns
Feature: DEBUG_COND_APPLICATION_IN_CLR_TXT
Entry : Input - 0x113f8758
Input : Vlan101
Output : <unknown>
Lapsed time : 200 ns
Feature: IPV4_INPUT_VFR
Entry : Input - 0x11416b68
Input : Vlan101
Output : <unknown>
Lapsed time : 320 ns
Feature: IPV4_INPUT_LOOKUP_PROCESS
Entry : Input - 0x11416610
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 3120 ns
Feature: IPV4_INPUT_IPOPTIONS_PROCESS
Entry : Input - 0x11416b28
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 360 ns
Feature: IPV4_INPUT_GOTO_OUTPUT_FEATURE
Entry : Input - 0x113fa4d0
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 1880 ns
Feature: CBUG_OUTPUT_FIA
Entry : Output - 0x113f8754
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 640 ns
Feature: IPV4_OUTPUT_VFR
Entry : Output - 0x11416b74
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 1240 ns
Feature: ALG PARSER
Type : DNS ALG
Caller : NAT
Action : OK
Feature: ALG PARSER
Type : DNS ALG
Caller : FW
Action : NO L7 ACTIONS
Feature: ZBFW
Action : Drop
Reason : AVC Policy drop:classify result
Zone-pair name : IN_OUT
Class-map name : INSIDE-TO-OUTSIDE-CLASS
Policy name : INSIDE-TO-OUTSIDE-POLICY
Input interface : Vlan101
Egress interface : GigabitEthernet0/0/0
Input VPN ID : 65535
Output VPN ID : 65535
Input VRF ID:Name : 0:
Output VRF ID:Name : 0:
AVC Classification ID : 1454
AVC Classification name: facebook
UTD Context ID : 0
Feature: OUTPUT_FNF_DROP_SDWAN
Entry : Output - 0x113fd270
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 1080 ns
Feature: OUTPUT_DROP
Entry : Output - 0x113f6c98
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 280 ns
Feature: IPV4_OUTPUT_INSPECT
Entry : Output - 0x114155c0
Input : Vlan101
Output : GigabitEthernet0/0/0
Lapsed time : 358960 ns
Packet Copy In
00b771b6 65f460eb 69513b3a 81000065 08004500 003a7594 00008011 9970c0a8
65020402 0202da90 00350026 232f5aed 01000001 00000000 00000866 61636562
Packet Copy Out
00b771b6 65f460eb 69513b3a 08004500 003a7594 00007f11 9a70c0a8 65020402
0202da90 00350026 232f5aed 01000001 00000000 00000866 61636562 6f6f6b03
It is very clear that the AVC feature tied to Zone Based Firewall is the one that has caused the drop. Upon looking at the config here is the section of the configuration that contributed to the drop.
zone-pair security IN_OUT source INSIDE destination OUTSIDE service-policy type inspect INSIDE-TO-OUTSIDE-POLICY policy-map type inspect INSIDE-TO-OUTSIDE-POLICY class type inspect INSIDE-TO-OUTSIDE-CLASS inspect service-policy avc AVC-POLICY class class-default drop class-map type inspect match-any INSIDE-TO-OUTSIDE-CLASS match protocol ftp match protocol http match protocol dns match protocol tcp match protocol udp match protocol icmp policy-map type inspect avc AVC-POLICY class AVC-CLASS deny class class-default allow class-map match-any AVC-CLASS match protocol yahoo match protocol amazon match protocol attribute category consumer-streaming match protocol attribute category gaming match protocol attribute category social-networking ===> This is the cause of the problem
As you can see AVC has blocked social-networking application.
Save the data
Save the packet trace details to the flash: show platform packet-trace summary | redirect bootflash:pkt_summary.txt show platform packet-trace packet all | redirect bootflash:pkt_all.txt
Cleanup
Clear the packet trace output: clear platform packet-trace statistics clear platform packet-trace configuration Cleanup: clear platform condition all conf t no ip access-list extended debug end
Scenario Two
Topology
Problem Description
Let us say that the PC at 14.36.109.13 is unable to telnet to 172.18.124.1. How can one troubleshoot this problem using packet tracer tool what steps are needed to configure it and capture the data.
Steps
Using packet trace is very straightforward. All you need to do is:
1. Write the condition for which you would like to gather the data
2. Specify what packets to capture and how many
3. Start, run the test and stop the condition
4. Save the data
5. Cleanup
Commands to enable packet tracer
Conditions to capture data
The command will match any packets coming in interface g0/0/0
kusankar-ASR1002#debug platform condition interface g0/0/0 ingress
This command will match any IPv4 packets coming in interface g0/0/3 with a src or dst IP 172.18.124.1.
kusankar-ASR1002#debug platform condition interface g0/0/0 ipv4 14.36.109.13/32 ingress
Specify what packets to trace
This command will collect 128 packets that matches what we defined to trace in the above step.
kusankar-ASR1002#debug platform packet-trace packet 128
Start the condition
Start the packet collection with the following command. Send the test traffic or try the telnet that fails then, stop the data collection.
Begin the packet capture:
kusankar-ASR1002#debug platform condition start
Run the problematic traffic for a few seconds
Then stop the packet capture:
kusankar-ASR1002#debug platform condition stop
See the packets captured
Once you find out what is being dropped we can focus on that particular packet to get more details. In this case packet 17,20 and 28 are dropped due to firewall policy. Let us see if this is the telnet packet from 14.36.109.13 destined to 172.18.124.1.
kusankar-ASR1002#sh platform packet-trace sum | i DROP Pkt Input Output State Reason 17 Gi0/0/0 Gi0/0/3 DROP 183 (FirewallPolicy) 20 Gi0/0/0 Gi0/0/3 DROP 183 (FirewallPolicy) 28 Gi0/0/0 Gi0/0/3 DROP 183 (FirewallPolicy)
This command below will give more detail about packet no: 17. Clearly the feature ZBFW is dropping the packet.
Now let us look closely into packet 17 and understand the input interface, output interface, source IP, destination IP, protocol and port.
kusankar-ASR1002#sh platform packet-trace packet 17
Packet: 17 CBUG ID: 3019
Summary
Input : GigabitEthernet0/0/0
Output : GigabitEthernet0/0/3
State : DROP 183 (FirewallPolicy)
Timestamp
Start : 15071588347061
Stop : 15071588471841
Path Trace
Feature: IPV4
Source : 14.36.109.13
Destination : 172.18.124.1
Protocol : 6 (TCP)
SrcPort : 52273
DstPort : 23 ===> This is the telnet traffic that is being dropped
Feature: ZBFW
Action : Drop
Reason : Policy drop due to classification result
Now examining the ZBF config closely the relevant config is as follows: Clearly tcp traffic is not allowed from the inside host 14.36.109.13
interface GigabitEthernet0/0/0 ip address 14.36.109.114 255.255.0.0 ip nat inside zone-member security INSIDE negotiation auto end ! interface GigabitEthernet0/0/3 ip address 172.18.124.41 255.255.255.0 ip nat outside zone-member security OUTSIDE negotiation auto end ! zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE service-policy type inspect INSIDE-pm zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE service-policy type inspect OUTSIDE-pm zone-member security INSIDE zone-member security OUTSIDE ! policy-map type inspect INSIDE-pm class type inspect in-out-class inspect class class-default ! class-map type inspect match-any in-out-class match protocol udp match protocol icmp match protocol ftp <====> Only udp icmp and ftp traffic is allowed. No tcp traffic is allowed and that is the reason telnet is breaking. ! end
Cleanup
Clear the packet trace output:
clear platform packet-trace statistics
clear platform packet-trace configuration
Cleanup:
clear platform condition all