The Lazy Networker

Tag: Cisco

  • What is Power over Ethernet (PoE)?

    Power over Ethernet (PoE) allows network cables to carry both data and electrical power to devices like IP phones, wireless access points, and security cameras, eliminating the need for separate power adapters.

    PoE Standards

    StandardMax Power per PortDevices Supported
    802.3af (PoE)15.4WPhones, small APs
    802.3at (PoE+)30WHigh-power APs, cameras
    802.3bt (PoE++)60-100WLED lights, laptops

    How to Enable PoE on a Cisco Switch

    Most Cisco switches support PoE by default, but you can manually enable or configure it.

    1. Check if the Switch Supports PoE

    Run:

    Switch#show power inline

    If you see available power and usage stats, the switch supports PoE.

    2. Enable PoE on an Interface

    Run:

    Switch#conf t
    interface <interface_id>
    power inline auto
    exit
    • <interface_id> → Example: GigabitEthernet1/0/1
    • auto → Enables PoE when a powered device (PD) is detected.

    To disable PoE on a port:

    Switch#conf t
    interface <interface_id>
    power inline never
    exit

    3. Set Power Limits for Devices

    By default, the switch assigns power dynamically. You can manually set power limits:

    Switch#conf t
    interface <interface_id>
    power inline static max 20000
    exit
    • Max power in milliwatts (mW)
      • 15000 for 15W (PoE)
      • 30000 for 30W (PoE+)
      • 60000 for 60W (PoE++)

    To check power consumption:

    Switch#show power inline interface <interface_id> detail

    4. Troubleshoot PoE Issues

    If a device is not powering up:

    • Check PoE status:bashCopyEditshow power inline interface <interface_id>
    • Reset PoE on the port:bashCopyEditconf t interface <interface_id> power inline never power inline auto exit
    • If the port is err-disabled, recover it:bashCopyEditconf t interface <interface_id> shutdown no shutdown exit
    • If power is exhausted, check:bashCopyEditshow power inline

    Summary

    TaskCommand
    Enable PoEpower inline auto
    Disable PoEpower inline never
    Set power limitpower inline static max <mW>
    Check PoE statusshow power inline
    Check port power useshow power inline interface <interface_id> detail

  • Troubleshooting Switch Interfaces

    Troubleshooting Cisco switch interface errors requires a structured approach to diagnose and resolve issues efficiently. Here’s a step-by-step guide:

    1. Check Interface Status

    Run:

    Switch#show interfaces status
    • Connected → Interface is up and functioning
    • Notconnect → No device is connected or a cable issue
    • Err-disabled → Error condition detected (see step 5)
    • Disabled → Interface is administratively down

    If the interface is down, enable it:

    Switch#conf t
    interface <interface_id>
    no shutdown
    exit

    2. Verify Cable and Physical Connection

    • Ensure the cable is properly plugged in.
    • Test with a different cable.
    • Check port LED status (blinking green = active, amber = issue).

    3. Check Interface Errors

    Run:

    Switch#show interfaces <interface_id>

    Look for:

    • Input errors: CRC errors, frame errors → Cable or duplex mismatch.
    • Output errors: Congestion or hardware failure.
    • CRC errors: Bad cables, interference, or duplex mismatch.
    • Collisions: High count may indicate a duplex mismatch.

    4. Check Duplex and Speed Settings

    Run:

    Switch#show interfaces <interface_id> status

    If there is a duplex mismatch, manually configure it:

    Switch#conf t
    interface <interface_id>
    duplex full
    speed 1000
    exit

    5. Check for Err-Disabled State

    Run:

    Switch#show interfaces status | include err-disabled

    Common causes:

    • Port security violation
    • BPDU guard violation
    • Link flap detection
    • UDLD failure

    Fix:

    Switch#conf t
    interface <interface_id>
    shutdown
    no shutdown
    exit

    To find the specific reason:

    Switch#show interfaces <interface_id> | include error

    If it’s due to port security:

    Switch#show port-security interface <interface_id>
    Switch#clear port-security sticky interface <interface_id>

    If BPDU guard triggered:

    Switch#spanning-tree bpduguard disable

    To automatically recover from err-disabled state:

    Switch#conf t
    errdisable recovery cause all
    errdisable recovery interval 30
    exit

    6. Check VLAN and Trunk Settings

    Run:

    Switch#show vlan brief

    Ensure the port is in the correct VLAN.

    For trunk ports:

    Switch#show interfaces trunk

    If VLANs are missing, add them:

    Switch#conf t
    interface <interface_id>
    switchport mode trunk
    switchport trunk allowed vlan add <vlan_id>
    exit

    7. Check Spanning Tree (STP) Issues

    Run:

    Switch#show spanning-tree interface <interface_id>
    • If the port is in Blocking state, STP is preventing loops.
    • If the port is flapping, check STP settings.

    To disable STP (use cautiously):

    Switch#conf t
    interface <interface_id>
    spanning-tree portfast
    exit

    8. Check MAC Address Table

    Run:

    Switch#show mac address-table interface <interface_id>

    If there are no MAC addresses, the device might not be communicating.

    9. Debugging Further

    To see real-time logs:

    Switch#terminal monitor
    debug spanning-tree events
    debug interface <interface_id>

    Disable debugging after use:

    Switch#undebug all

    10. Reload Interface or Switch

    If all else fails:

    Switch#reload

    or shut/no shut the interface.

  • EVE-NG Installation on VMware Workstation

    Installing EVE-NG on VMware Workstation involves several steps. Here’s a step-by-step guide:

    Prerequisites

    1. VMware Workstation Pro or VMware Workstation Player installed.
    2. EVE-NG ISO or OVA downloaded from EVE-NG website.
    3. Adequate System Requirements:
      • At least 4 CPU cores (8+ recommended).
      • 16GB RAM (More for large labs).
      • 100GB+ SSD storage.
      • Intel VT-x/EPT or AMD-V/RVI enabled in BIOS.
      • VMware installed with nested virtualization support enabled.

    Method 1: Install EVE-NG using OVA (Recommended)

    Step 1: Download the EVE-NG OVA File

    • Download the EVE-NG Community OVA or EVE-NG Professional OVA from EVE-NG.net.

    Step 2: Import the OVA in VMware

    1. Open VMware Workstation.
    2. Click File → Open.
    3. Select the EVE-NG OVA file.
    4. Click Import and wait for the process to complete.

    Step 3: Adjust VM Settings

    • Increase CPU Cores (Recommended: 4 or more).
    • Increase RAM (Recommended: 8GB or more).
    • Set Network Adapter to Bridged (for external access).
    • Enable Nested Virtualization:
      • Go to Processors → Enable “Virtualize Intel VT-x/EPT or AMD-V/RVI”.

    Step 4: Start the VM & Configure EVE-NG

    1. Power on the VM.
    2. Login using default credentials:
      • Username: root
      • Password: eve
    3. Change the root password when prompted.
    4. Configure network settings using the CLI or DHCP.
    5. Access the web GUI via **http://<EVE-NG-IP>/`.

    Method 2: Install EVE-NG from ISO (Manual Installation)

    Step 1: Create a New VM

    1. Open VMware Workstation and click Create a New Virtual Machine.
    2. Select “Custom (Advanced)” and click Next.
    3. Choose “I will install the operating system later” and click Next.
    4. Select Linux → Ubuntu 64-bit.
    5. Name the VM (e.g., EVE-NG) and choose the storage location.

    Step 2: Configure VM Settings

    • CPU: At least 4 cores (More recommended).
    • RAM: At least 8GB (More recommended).
    • Hard Disk: 100GB or more.
    • Network Adapter: Set to Bridged or NAT.
    • Enable Virtualization: Go to Processors and enable VT-x/EPT.

    Step 3: Mount & Install EVE-NG

    1. Attach the EVE-NG ISO:
      • Go to CD/DVD (IDE) settings.
      • Select “Use ISO Image File” and browse for the EVE-NG ISO.
    2. Power on the VM.
    3. Follow the installation wizard:
      • Choose Install EVE-NG.
      • Select disk and proceed with the installation.
      • Set up a root password.
      • Configure network settings.
    4. After installation, reboot the VM.

    Step 4: Access EVE-NG

    • Login via CLI using:makefileCopyEditUsername: root Password: (your password)
    • Find the IP address of the VM (ifconfig or ip a).
    • Open a web browser and go to http://<EVE-NG-IP>/.

    Post-Installation Steps

    1. Enable SSH & Web GUI Access

    • Ensure EVE-NG is reachable from your network.
    • Use a browser to access the Web GUI at http://<EVE-NG-IP>/.

    2. Upload & Install Network Images

    • Upload images (Cisco, Juniper, Fortinet, etc.) to /opt/unetlab/addons/qemu/.
    • Fix permissions using:bashCopyEdit/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

    3. Connect to the Lab

    • Use SecureCRT, Putty, or the built-in console to connect to network devices.

    Troubleshooting

    1. Web GUI Not Accessible?
      • Check network settings and ensure Bridged Adapter is selected.
      • Try systemctl restart networking inside EVE-NG.
    2. VM Won’t Boot?
      • Enable VT-x/EPT in BIOS.
      • Ensure Nested Virtualization is enabled in VMware.
    3. Slow Performance?
      • Allocate more CPU cores and RAM.
      • Ensure SSD storage is used.

  • MAC address learning process

    A switch learns MAC addresses using a process called MAC address learning or learning and forwarding. Here’s how it works:

    1. Receives a Frame: When a switch receives an Ethernet frame on a port, it examines the frame’s source MAC address.
    2. Updates the MAC Table (CAM Table):
      • The switch stores the source MAC address and the port number in its MAC address table (also called the Content Addressable Memory (CAM) table).
      • This way, the switch knows which device is connected to which port.
    3. Forwards the Frame:
      • If the destination MAC address is already in the MAC table, the switch forwards the frame only to the corresponding port.
      • If the destination MAC address is not in the table, the switch floods the frame to all ports except the one it was received from. This is called unknown unicast flooding.
    4. Refreshes Entries:
      • MAC address entries have a timeout (typically 5 minutes by default).
      • If a device doesn’t send traffic for a while, its MAC entry is removed from the table to free up space.

    Example Scenario:

    • A device with MAC AA:BB:CC:DD:EE:01 sends a frame through Port 1.
    • The switch records AA:BB:CC:DD:EE:01 → Port 1 in its MAC table.
    • If the destination MAC is unknown, the switch floods the frame.
    • When the destination device responds, the switch learns its MAC and updates the table.

    This process helps switches efficiently forward traffic and reduce unnecessary network congestion.

  • Cisco SD-WAN Templates

    Cisco SD-WAN uses device and feature templates to manage configurations efficiently across multiple devices. Here’s a breakdown of how these templates work:

    • Device Templates: These are specific to a device model, such as vEdge routers, and are used to configure the complete operational setup of a device. A device template consists of one or more feature templates. Device templates can be customized for different locations or roles within a network.
    • Feature Templates: These templates define configurations for specific software features on Cisco SD-WAN devices. They can be applied across multiple device types and are used to configure parameters like system settings, interfaces, routing protocols, and security settings. Feature templates can be mandatory or optional, and some have default configurations that can be overridden.
    • Parameter Scope: Parameters in feature templates can have different scopes:
      • Device Specific: Values are unique to each device and are entered when attaching a device template to a specific device. Examples include system IP address, hostname, and GPS location.
      • Global: Values apply to all devices using the template, such as DNS server settings or interface MTUs.
    • CSV Files: Device-specific settings can be managed using CSV files. Each row in the CSV file corresponds to a device, with columns for parameters like device ID, IP address, and hostname. These files are uploaded when attaching a device template to a device.
    • Template Creation: Templates can be created from feature templates or via the CLI. Mandatory feature templates and some optional ones have default configurations. Custom templates can be created to tailor configurations to specific needs.
    • Configuration Management: Templates help in managing configurations across multiple devices, reducing human error and scaling issues. They support features like zero-touch provisioning (ZTP) and automatic rollback, ensuring efficient and error-free deployment.

    These templates streamline the configuration process, making it easier to manage and scale Cisco SD-WAN networks.

  • Python script to check the Cisco IOS version and perform upgrades or downgrades as needed

    This script will utilize the Netmiko library for SSH connections and the NAPALM library for device configuration management.

    Script Requirements

    1. Python 3.x
    2. Netmiko library (install using pip install netmiko)
    3. NAPALM library (install using pip install napalm)
    4. Cisco IOS device(s) with SSH enabled
    5. A configuration file (e.g., config.yaml) defining the recommended IOS versions for each device model
    6. A directory containing the IOS image files (e.g., images/) matching the device models and recommended versions

    Script Structure

    The script will consist of the following components:

    1. Device Connection: Establish an SSH connection to the Cisco device using Netmiko.
    2. IOS Version Check: Retrieve the current IOS version from the device using NAPALM.
    3. Configuration Check: Compare the current IOS version with the recommended version defined in the configuration file.
    4. Upgrade/Downgrade: Perform the necessary upgrade or downgrade using NAPALM, if the current version does not match the recommended version.
    5. Image Transfer: Transfer the required IOS image file from the images/ directory to the device using SCP (or other transfer method).

    Script Code

    Here’s a sample script to get you started:

    import os
import yaml
from netmiko import SSHNetmiko
from napalm.base import get_network_driver

# Configuration file path
config_file = 'config.yaml'

# Device model to IOS image mapping
device_models = {
    'WS-C3560X-48P': 'c3560e-universalk9-mz.122-55.SE8.bin'
}

# Recommended IOS versions for each device model
recommended_versions = {
    'WS-C3560X-48P': '15.2(4)E8'
}

def get_current_ios_version(device):
    # Establish SSH connection using Netmiko
    ssh = SSHNetmiko(device['ip'], username='your_username', password='your_password')
    # Retrieve current IOS version using NAPALM
    ios_version = ssh.get_facts()['ios_version']
    return ios_version

def check_ios_version(current_version, recommended_version):
    if current_version != recommended_version:
        return True  # Version mismatch, upgrade/downgrade required
    return False  # Version matches, no action needed

def upgrade_or_downgrade(device, current_version, recommended_version):
    # Determine upgrade/downgrade direction
    if current_version < recommended_version:
        direction = 'upgrade'
    elif current_version > recommended_version:
        direction = 'downgrade'
    else:
        return  # No action needed

    # Transfer required IOS image file using SCP
    image_file = os.path.join('images/', device_models[device['model']])
    ssh.scp.put(image_file, '/tmp/')

    # Perform upgrade/downgrade using NAPALM
    if direction == 'upgrade':
        ssh.load_replace_candidate(filename='/tmp/' + image_file)
        ssh.commit_config()
    elif direction == 'downgrade':
        ssh.load_replace_candidate(filename='/tmp/' + image_file, replace='exact')
        ssh.commit_config()

    # Reload the device to apply changes
    ssh.send_command('reload')

def main():
    with open(config_file, 'r') as f:
        config_data = yaml.safe_load(f)

    for device in config_data['devices']:
        current_version = get_current_ios_version(device)
        recommended_version = recommended_versions[device['model']]
        if check_ios_version(current_version, recommended_version):
            upgrade_or_downgrade(device, current_version, recommended_version)

if __name__ == '__main__':
    main()

    Note

    1. Replace your_username and your_password with your actual SSH credentials.
    2. Update the device_models dictionary to match your specific device models and corresponding IOS image files.
    3. Modify the recommended_versions dictionary to reflect the desired IOS versions for each device model.
    4. Ensure the images/ directory contains the required IOS image files.
    5. This script is a starting point and may require additional error handling, logging, and testing to ensure its reliability.

    Remember to test the script in a lab environment before deploying it to production 🙂

  • Python script to check if VDB databases are updated in Cisco FMC

    To check if VDB databases are updated in Cisco FMC and print the results to an Excel file using Python, you can use the following approach:

    1.Access Cisco FMC through API: Use the Cisco FMC API to retrieve the VDB database information. You can find more details about the API in the Cisco FMC API documentation.

    import requests
    import json

    fmc_feeds_url = “https://10.10.10.10/api/fmc_feeds/access&#8221;
    fmc_headers = {‘content-type’: ‘application/json’}
    fmc_auth = (‘admin’, ‘YourPassword’) # replace ‘YourPassword’ with your actual password

    response = requests.get(fmc_feeds_url, headers=fmc_headers, auth=fmc_auth, verify=False)
    feeds = json.loads(response.text)

    2.Parse the API response: Extract the VDB database information from the API response.

    vdb_databases = [feed for feed in feeds[‘items’] if feed[‘name’].startswith(‘VDB’)]

    3.Create an Excel file and print the results: Use a library like pandas to create an Excel file and print the results.

    import pandas as pd

    df = pd.DataFrame(vdb_databases)
    df.to_excel(‘VDB_databases.xlsx’, index=False)

  • How to set up AnyConnect VPN in Cisco Firepower Threat Defense (FTD)

    How to set up AnyConnect VPN in Cisco Firepower Threat Defense (FTD)

    here’s a step-by-step guide on how to set up AnyConnect VPN in Cisco Firepower Threat Defense (FTD):

    Prerequisites

    1. Ensure you have a valid AnyConnect license for your FTD device.
    2. Familiarize yourself with the FTD device model and its maximum concurrent remote access VPN sessions (refer to the “Device Model” table in the search results).

    Step 1: Configure Remote Access VPN Policy

    1. Log in to the Firepower Management Center (FMC) web interface.
    2. Navigate to Objects > VPN > Remote Access VPN Policy.
    3. Create a new policy or edit an existing one.
    4. Configure the policy settings, such as:
      • VPN protocol (SSL or IPsec-IKEv2)
      • Authentication method (e.g., client certificate, username/password)
      • Authorization and accounting settings
      • URL Aliases (if required)

    Step 2: Configure Client Profiles

    1. Navigate to Objects > VPN > Client Profiles.
    2. Create a new profile or edit an existing one.
    3. Configure the profile settings, such as:
      • AnyConnect module (e.g., AMP Enabler, ISE Posture)
      • Profile type (e.g., XML, ASP)
      • File extension (refer to the “Table 8. Supported File Extensions of Profiles” in the search results)

    Step 3: Upload AnyConnect Images

    1. Navigate to Objects > VPN > AnyConnect Images.
    2. Upload the required AnyConnect images (based on the operating system requirements).
    3. Select the desired image for each operating system (e.g., Windows, macOS, iOS, Android).

    Step 4: Configure Remote Access VPN Connection

    1. Navigate to Devices > Remote Access.
    2. Select the FTD device and click Edit.
    3. Configure the remote access VPN connection settings, such as:
      • VPN protocol
      • Authentication method
      • Authorization and accounting settings
      • Split tunneling (if required)

    Step 5: Save and Deploy Policy

    1. Save the remote access VPN policy.
    2. Deploy the policy to the FTD device.

    Step 6: Verify AnyConnect Client Installation

    1. Ensure that the AnyConnect client is installed on the remote user’s device.
    2. Verify that the client is configured to connect to the FTD device using the correct VPN protocol and settings.

    Additional Considerations

    • Ensure that the FTD device is configured to allow remote access VPN connections.
    • Verify that the FTD device has sufficient resources (e.g., CPU, memory) to handle the maximum concurrent remote access VPN sessions.
    • Consider configuring NAT exemption and hairpinning (if required) to allow AnyConnect clients to access internal resources.

    By following these steps and considering the additional considerations, you should be able to successfully set up AnyConnect VPN in your Cisco FTD device.

  • Deleting a Stuck Deployment Notification in Cisco FMC

    Deleting a Stuck Deployment Notification in Cisco FMC

    Its frustrating it can be when a Cisco Firepower Threat Defense (FTD) deployment gets stuck and keeps showing up in notifications. Let’s sort it out this issue:

    1. Deleting a Stuck Deployment Notification:
      • To remove a stuck deployment notification, follow these steps:
        1. Log in to the Firepower Management Center (FMC).
    2. Switch to the root user:
      • expert
      • sudo su –
    3. Use the OmniQuery.pl tool to query the database and find the running tasks:
      • OmniQuery.pl -db mdb -e “select status, category, hex(uuid), body from notification;” | grep ” \ 7\ “
    4. Identify the UUID of the running task.
    5. Delete the deployment notification using one of the following commands:
      • OmniQuery.pl -db mdb -e “delete from notification where uuid=unhex(‘YOUR_UUID_HERE’);”
    6. The notification should clear out after a 5-minute health check or can be manually cleared from the Health

  • How to use Packet Tracer on Cisco ASA

    How to use Packet Tracer on Cisco ASA

    Packet tracer feature used to verify the security mechanisms as packet moves from one interface to another in a cisco ASA firewall. By this we can troubleshoot why the traffic is not working in the firewall or whether we created the rule correctly or not

    A typical series of security features tested might look like the following:

    • Flow lookup: Checks for existing xlate and conn entries.
    • UN-NAT: Checks for address translation entries.
    • Access list lookup: Checks for any applicable ACL entries.
    • IP options lookup: Checks handling of IP options in the ingress packet.
    • NAT: Checks the Reverse Path Forwarding (RPF) information.
    • NAT: Checks for host connection limits.
    • IP options lookup: Checks handling of IP options in egress packet.
    • Flow creation: Creates new xlate and conn entries, if needed.
    • Route lookup: Checks for a router to the destination address.

    Using Packet Tracer

    • Login to the ASA and go to enable mode:
    • login as: admin
    • dmin@10.1.10.1
    • password: Type help or ‘?’ for a list of available commands.
    • Corp-Hq-Fw01> en Password: Corp-Hq-Fw01#
    • Gather the required information for your packet trace:
      • The interface you wish the traffic to originate from
      • The type of traffic you wish to spoof, with TCP, UDP, ICMP (all types) or RawIP traffic supported.
      • The source port (if applicable) you want the traffic to originate from.
      • The destination port (again, if applicable) you want the traffic to be destined to.

    Now type in the command, syntax is

    packet-tracer input $source-interface $traffic-type $src_address $src_proto $src_proto_options $dest_address
    • In this instance let’s test
    • Inside interface address
    • ICMP traffic
    • Destined for google 8s

    Corp-Hq-Fw01# packet-tracer input inside icmp 10.1.10.5 8 0 8.8.8.8

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: Resolve Egress Interface
 Result: ALLOW
 Config:
 Additional Information:
 found next-hop X.X.X.X using egress ifc OUTSIDE

Phase: 2
 Type: ACCESS-LIST
 Subtype:
 Result: DROP
 Config:
 Implicit Rule
 Additional Information:

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: OUTSIDE
 output-status: up
 output-line-status: up
 Action: drop
 Drop-reason: (acl-drop) Flow is denied by configured rule

    The traffic is blocked in the firewall because there is no rule for created for ICMP. Lets do the test again after creating rule to allow ICMP in the firewall 

    Corp-Hq-Fw01# packet-tracer input inside icmp 10.1.10.5 8 0 8.8.8.8

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: Resolve Egress Interface
 Result: ALLOW
 Config:
 Additional Information:
 found next-hop X.X.X.X using egress ifc OUTSIDE

Phase: 2
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 object network REDOUBT
 nat (inside,OUTSIDE) static X.X.X.X
 Additional Information:
 Static translate 10.1.10.0/0 to X.X.X.X/0

Phase: 3
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 4
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 5
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 6
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (any,OUTSIDE) after-auto source dynamic any interface
 Additional Information:

Phase: 8
 Type: USER-STATISTICS
 Subtype: user-statistics
 Result: ALLOW
 Config:
 Additional Information:

Phase: 9
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 10
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 11
 Type: USER-STATISTICS
 Subtype: user-statistics
 Result: ALLOW
 Config:
 Additional Information:

Phase: 12
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 725694429, packet dispatched to next module

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: OUTSIDE
 output-status: up
 output-line-status: up
 Action: allow

    As you can see above, ping passes through the firewall successfully

    • You can see the initial routing decision(Phase 1),
    • that the traffic hit the outside interface NAT (Phase 2 & 3)
    • and that it passed ICMP inspection (Phase 5)