ASA FirePOWER Licensing

ASA FirePOWER Module Licenses

Licenses allow your device to perform a variety of functions including:

  • Intrusion Detection and Prevention
  • Security Intelligence filtering
  • File Control and Advanced Malware Protection
  • Application, User, and URL Control

Certain licenses, like the Control license, are perpetual. Other licenses require that you purchase a service subscription to enable the license.

License Type  Service Subscription Capabilities Prerequisite Expire Capable
Protection TA Intrusion Detection and Prevention, File Control,
Security Intelligence Filtering
None No
Control None (included with module) User and Application Control Protection No
Malware TAM, TAMC, AMP Advanced Malware
Protection (Network-based
Malware Detection and
Blocking)
Protection Yes
URL Filtering TAC, TAMC, URL Category and Reputation-based URL Filtering Protection Yes
Service Subscriptions
Subscription Types License You Assign in FirePOWER System
TA Control + Protection (a.k.a. “Threat & Apps,” required for system updates)
TAC Control + Protection + URL Filtering
TAM Control + Protection + Malware
TAMC Control + Protection + URL Filtering + Malware
AMP Malware (add-on where TA is already present)
URL URL Filtering (add-on where TA is already present)

TA – Threat & Apps License required for system updates
TAC – URL Filtering license as a services subscription combined with Threat & Apps
TAM – Malware license as a subscription combined with Threat & Apps
TAMC – Malware license as a subscription combined with Threat & Apps and URL Filtering
AMP – Advanced Malware Protection License
URL – URL Filtering License

Protection License
  • Intrusion Detection and Prevention – It allows you to analyze network traffic for intrusions and exploits and, optionally, drop offending packets.
  • File control – It allows you to detect and, optionally, block users from uploading or downloading files of specific types over specific application protocols. With a Malware license , you can also inspect and block a restricted set of those file types
    based on their malware dispositions.
  • Security Intelligence Filtering – It allows you to blacklist (deny traffic to and from) specific IP addresses, before the traffic is subjected to analysis by access control rules.  Dynamic feeds allow to immediately blacklist connections based on the latest intelligence. Optionally, you can use a “monitor-only” setting for Security Intelligence filtering.

A Protection license is automatically included (along with a Control license) in the purchase of an ASA FirePOWER module. This license is perpetual, but you must also purchase a TA subscription to enable system updates.

Control License

A Control license allows you to implement user and application control by adding user and application conditions to access control rules. To enable Control, you must also enable Protection.

A Control license is automatically included (along with a Protection license) in the purchase of an ASA FirePOWER module. This license is perpetual, but you must also purchase a TA subscription to enable system updates.

Malware License

A Malware license allows you to perform advanced malware protection, that is, use devices to detect and block malware in files transmitted over your network. To enable Malware on a device, you must also enable Protection.

URL Filtering License

URL filtering allows you to write access control rules that determine the traffic that can traverse network based on URLs requested by monitored hosts, correlated with information about those URLs, which is obtained from the Cisco cloud by the ASA FirePOWER module. To enable URL Filtering, you must also enable a Protection license.

QoS Classification and Marking

QoS classification tools categorize packets by examining the contents of the frame, cell, and packet headers, whereas marking tools allow the QoS tool to change the packet headers for easier classification.

Most QoS tools classify traffic, which allows for each class of traffic to receive a different level of treatment from other traffic classes. These different types or classes of traffic are typically called service classes in QoS terminology.

To place voice and data traffic in separate queues, for example, you must use some form of classification to differentiate the two types of traffic and place the identified traffic in the proper queue.

Marking provides a way for QoS tools to change bits in the packet header to indicate the level of service this packet should receive from other QoS tools. For instance, you can use marking tools to change the marking in voice packets to ensure that a classification tool can differentiate a voice packet from a data packet.

Classification Tools

Class-Based Marking (CB-Marking) – CB Marking can also refer to access control lists (ACLs) to match packets, with packets permitted by an ACL being considered to match the logic used by CB Marking.

Classification with NBARNBAR classifies packets that are normally difficult to classify. For instance, some applications use dynamic port numbers, so a statically configured match command, looking for a particular UDP or TCP port number, simply could not classify the traffic. NBAR can look past the UDP and TCP header, and refer to the host name, URL, or MIME type in HTTP requests. This deeper examination of the packet contents is sometimes called deep packet inspection.

Marking

Marking involves setting some bits inside a data link or network layer header, with the goal of letting other devices’ QoS tools classify traffic based on the marked values.

QoS Marking Fields

The specific fields which can be used for QoS Marking are as follows:

Field Location Length
IP Precedence (IPP) IP Header 3 bits
IP DSCP (Differentiated Services Code Point) IP Header 6 bits
DS Field (Differentiated Services) IP Header 1 Byte
ToS Byte (Type of Service) IP Header 1 Byte
CoS (Class of Service) ISL and 802.1Q Header 3 bits
Discard Eligible (DE) Frame Relay Header 1 bit
Cell Loss Priority (CLP) ATM Cell Header 1 bit
MPLS Experimental (EXP) MPLS Header 3 bits
Legacy ToS Field

The IP header defined in RFC 791, includes a 1 Byte field called the “Type of Service (ToS). The ToS byte was intended to be used as a field to mark a packet for QoS. The ToS byte was further subdivided with the high-order 3 bits (0 through 2) defined as the IP Precedence (IPP) field. The bits 3 through 6 of the ToS Byte included flag fields that were toggled on (1) or off (0) to imply a particular QoS service. The final bit 7 was not defined in RFC791. The flags were not used very often. The main purpose of the ToS byte was to hold 3-bit IPP field.

                              -----------
                               IP Header
                              -----------

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          ----------------------------------------------------
           The Type of Service octet consists of three fields
          ----------------------------------------------------

                0     1     2     3     4     5     6     7
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                 |                       |     |
             |   PRECEDENCE    |          TOS          | MBZ |
             |                 |                       |     |
             +-----+-----+-----+-----+-----+-----+-----+-----+
First 3 bits (0 through 2) of ToS / IP Precedence

The Precedence field values imply that the larger the value, the more important the traffic.

Field and Value (Decimal) Binary Value Name
Precedence 0 000 Routine
Precedence 1 001 Priority
Precedence 2 010 Immediate
Precedence 3 011 Flash
Precedence 4 100 Flash Override
Precedence 5 101 Critic/Critical/ECP
Precedence 6 110 Internetwork Control
Precedence 7 111 Network Control
Next 4 bits (3 through 6) of TOS Values (RFC1349)

0000 — normal service (Default)
0001 — minimize monetary cost
0010 — maximize reliability
0100 — maximize throughput
1000 — minimize delay

The last field labeled “MBZ” was unused.

Modern DS Field (Differentiated Services)

The ToS field was updated by series of RFCs and the field itself was renamed as Differentiated Services (DS) field. IPP field of ToS byte was replaced with a 6-bit (high order bits 0 through 5) field called the Differentiated Services Code Point (DSCP) field. The RFC3168 defined the low order 2 bits (bits 6 through 7) of DS field for use with the QoS Explicit Congestion Notification (ECN) feature.

 

 

 

 

 

 

 

Differentiated Services Architectural Model

The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single Differentiated Services Code Point (DSCP). Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DSCP. RFC2475

Behavior Aggregates and Per-Hop Behavior

 

 

 

 

 

 

 

 

The Class Selector PHB and DSCP Values

The DS field is simply a redefinition of the original ToS Byte in the IP Header. IP Precedence (IPP) filed of ToS Byte overlaps with first 3-bits of DSCP field of DS field. Because of this overlap, RFC2475 defines a set of DSCP values and PHBs, called Class Selector (CS) PHBs, that provide backward compatibility with IPP.

DSCP Class Selector Names Binary Value of DSCP Binary Value of IPP IPP Field and Decimal Value IPP Name
CS0 (Default) 000000 000 Precedence 0 Routine
CS1 001000 001 Precedence 1 Priority
CS2 010000 010 Precedence 2 Immediate
CS3 011000 011 Precedence 3 Flash
CS4 100000 100 Precedence 4 Flash Override
CS5 101000 101 Precedence 5 Critic/Critical/ECP
CS6 110000 110 Precedence 6 Internetwork Control
CS7 111000 111 Precedence 7 Network Control
Assured Forwarding PHB and DSCP Values

RFC 2597 defines four classes of Assured Forwarding (AF) PHB for queuing purpose, along with the three levels of drop probability inside each queue. To mark packets and distinguish into which of four queues a packet should be placed, along with one of three drop priorities inside each queue, the AF PHB defines 12 DSCP values and their meanings. The names of the AF DSCPs conform to the following format:

AFxy

where x implies one of the four queues (values 1-4) and y implies one of the three drop probabilities (values 1-3).

To convert from the AF name to the decimal equivalent, you can use a simple formula.

If you think of the AF values as AFxy, the formula is 8x + 2y = decimal value

For example, AF41 gives you a formula of (8 x 4) + (2 x 1) = 34

Queue Class Low Drop Probability Within Class Medium Drop Probability Within Class High Drop Probability Within Class
Name/Decimal/Binary Name/Decimal/Binary Name/Decimal/Binary
Class 1 AF11/10/001010 AF12/12/001100 AF13/14/001110
Class 2 AF21/18/010010 AF22/20/010100 AF23/22/010110
Class 3 AF31/26/011010 AF32/32/011100 AF33/30/011110
Class 4 AF41/34/100010 AF42/42/100100 AF43/38/100110
Commonly Used DSCP Values
DSCP Value Decimal Value Meaning Drop Probability Equivalent IP Precedence Value
101 110 46 High Priority Expedited Forwarding (EF) N/A 101 – Critical
000 000 0 Best Effort N/A 000 – Routine
001 010 10 AF11 Low 001 – Priority
001 100 12 AF12 Medium 001 – Priority
001 110 14 AF13 High 001 – Priority
010 010 18 AF21 Low 010 – Immediate
010 100 20 AF22 Medium 010 – Immediate
010 110 22 AF23 High 010 – Immediate
011 010 26 AF31 Low 011 – Flash
011 100 28 AF32 Medium 011 – Flash
011 110 30 AF33 High 011 – Flash
100 010 34 AF41 Low 100 – Flash Override
100 100 36 AF42 Medium 100 – Flash Override
100 110 38 AF43 High 100 – Flash Override
001 000 8 CS1 1
010 000 16 CS2 2
011 000 24 CS3 3
100 000 32 CS4 4
101 000 40 CS5 5
110 000 48 CS6 6
111 000 56 CS7 7
The Expedited Forwarding PHB and DSCP Values

RFC 2598 defines the expedited forwarding per-hop behaviors. This RFC defines a very simple PHB (low latency, with a cap on bandwidth), and a single DSCP (EF) to represent it. Expedited forwarding simply states that a packet with the EF DSCP should minimize delay, jitter, and loss, up to a guaranteed bandwidth level for the class.

The expedited forwarding PHB uses a DSCP name of EF, whose binary value is 101110, with a decimal value of 46.

Ethernet LAN CoS (Class of Service)

The CoS (Class of Service) field only exists inside Ethernet frames when 802.1Q or Inter-Switch Link (ISL) trunking is used. The IEEE 802.1P standard actually defines the usage of the CoS bits inside the 802.1Q header. It is called CoS (Class of Service) in ISL header and   “User-Priority bits” in 802.1Q tag field. But in general, it is referred as CoS field regardless of the type of trunking.

 

 

 

 

 

 

 

WAN Marking Fields

You can use single-bit fields in Frame Relay and ATM networks to mark a frame or cell for Layer 2 QoS. Frame Relay defines the discard eligibility (DE) bit, and ATM defines the cell loss priority (CLP) bit. The general idea is that when a device, typically a WAN switch, experiences congestion, it needs to discard some frames or cells. If a frame or cell has the DE or CLP bit set, respectively, the switch may choose to discard those frames or cells, and not discard other frames or cells. If the DE or CLP bit is set, there is no requirement that the Frame Relay and ATM switches react to it, just like there is no guarantee that an IP packet with DSCP EF will get special treatment by another router. It’s up to the owner of the Frame Relay or ATM switch to decide whether it will consider the DE and CLP bits, and how to react differently.

The MPLS Experimental bits comprise a 3-bit field that you can use to map IP precedence into an MPLS label.

Frame Relay Header

 

 

 

 

 

 

ATM Cell Header

 

 

 

 

 

 

 

 

 

 

MPLS Header

 

 

 

 

QoS Values Calculator

Reference: http://www.netcontractor.pl/blog/wp-content/uploads/2011/11/QoS-Values-Calculator-v3.jpg

Classification and Marking Design Choices

In summary, classification and marking tools classify packets based on a large number of different fields inside data link and network layer headers. Based on the classification, the tools then mark a field in a frame or packet header, with the goal that other QoS tools can more easily classify and perform specific QoS actions based on these marked fields. Among all the fields that can be marked, IP Precedence and DSCP, because they are part of the IP header, are the only fields that can be marked and carried from end to end in the network.

Cisco Recommended QoS Baseline

 

 

 

 

 

 

https://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295a9b.pdf

 

Cisco IOS Packages and Licenses

Feature Sets/Technology Package
  1. IP Base (ipbasek9) – Entry level Cisco IOS functionality. Some of the key feature are AAA BGP, OSPF, EIGRP, ISIS, RIP, PBR, IGMP, Multicast, DHCP, HSRP, GLBP, NHRP, HTTP, HQF QoS ACL, NBAR GRE CDP, ARP NTP PPP PPPoA PPPoE RADIUS TACACS, RSVP, NTP, Flexible Netflow etc.
  2. DATA  (datak9) – Data features found in SP Services and Enterprise Services IOS image on ISR Routers. It support MPLS, ATM, and Multiprotocol support.
  3. Security (securityk9) – It support Cisco IOS Firewall , IPS , IPsec , 3DES, VPN etc.
  4. Unified Communications (uck9) – It support VOIP & IP Telephony

 

Universal IOS Packaging Overview

ISR Integrated Service Router comes with IPbase feature set and we need to get the license package to  run the other three technology packages.

License Types Available on ISR Routers
Permanent Licenses

Permanent licenses are valid for the life of the device on which it is installed. Some examples of permanent licenses are IOS Technology Packages (IPBase, UC, SEC, DATA), Feature Licenses such as SSL VPN etc.

Temporary Licenses

Temporary licenses are used for evaluating new capabilities or in emergency situations. A temporary license allows a feature set to be used for 60 days of actual usage. When the 60-day period expires, the device will continue to operate normally until reloaded. After the reload, the device will default to the original functionality before the temporary license was enabled. Only actual time that the temporary license is enabled counts towards the 60 day limit. The Cisco Technical Assistance Center (TAC) can provide an extension license for longer trials or other circumstances.

 

Cisco ISR4000 Series Router Securityk9 Evaluation License

Evaluation License

Your router comes with the evaluation license, also known as a temporary license, for most packages and features supported on your router. If you want to try a new software package or feature, activate the evaluation license for that package or feature.

We will install security evaluation license here. Let’s first verify existing license status.

Router#show license all 
License Store: Primary License Storage
StoreIndex: 0 Feature: uck9 Version: 1.0
 License Type: Permanent
 License State: Active, In Use
 License Count: Non-Counted
 License Priority: Medium
StoreIndex: 1 Feature: ipbasek9 Version: 1.0
 License Type: Permanent
 License State: Active, In Use
 License Count: Non-Counted
 License Priority: Medium
License Store: Built-In License Storage
StoreIndex: 0 Feature: appxk9 Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA not accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: None
StoreIndex: 1 Feature: uck9 Version: 1.0
 License Type: EvalRightToUse
 License State: Inactive
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: None
StoreIndex: 2 Feature: securityk9 Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: Low
StoreIndex: 3 Feature: FoundationSuiteK9 Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA not accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: None
StoreIndex: 4 Feature: AdvUCSuiteK9 Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA not accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: None
StoreIndex: 5 Feature: cme-srst Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA not accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: 0/0 (In-use/Violation)
 License Priority: None
StoreIndex: 6 Feature: throughput Version: 1.0
 License Type: EvalRightToUse
 License State: Active, Not in Use, EULA not accepted
 Evaluation total period: 8 weeks 4 days 
 Evaluation period left: 8 weeks 4 days 
 Period used: 0 minute 0 second 
 License Count: Non-Counted
 License Priority: None

Install evaluation security license.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#license boot level securityk9
PLEASE READ THE FOLLOWING TERMS CAREFULLY. INSTALLING THE LICENSE OR
LICENSE KEY PROVIDED FOR ANY CISCO PRODUCT FEATURE OR USING SUCH
PRODUCT FEATURE CONSTITUTES YOUR FULL ACCEPTANCE OF THE FOLLOWING
TERMS. YOU MUST NOT PROCEED FURTHER IF YOU ARE NOT WILLING TO BE BOUND
BY ALL THE TERMS SET FORTH HEREIN.

Use of this product feature requires an additional license from Cisco,
together with an additional payment. You may use this product feature
on an evaluation basis, without payment to Cisco, for 60 days. Your use
of the product, including during the 60 day evaluation period, is
subject to the Cisco end user license agreement
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html
If you use the product feature beyond the 60 day evaluation period, you
must submit the appropriate payment to Cisco for the license. After the
60 day evaluation period, your use of the product feature will be
governed solely by the Cisco end user license agreement (link above),
together with any supplements relating to such product feature. The
above applies even if the evaluation license is not automatically
terminated and you do not receive any notice of the expiration of the
evaluation period. It is your responsibility to determine when the
evaluation period is complete and you are required to make payment to
Cisco for your use of the product feature beyond the evaluation period.

Your acceptance of this agreement for the software features on one
product shall be deemed your acceptance with respect to all such
software on all Cisco products you purchase which includes the same
software. (The foregoing notwithstanding, you must purchase a license
for each software feature you use past the 60 days evaluation period,
so that if you enable a software feature on 1000 devices, you must
purchase 1000 licenses for use past the 60 day evaluation period.)

Activation of the software command line interface will be evidence of
your acceptance of this agreement.



ACCEPT? (yes/[no]): yes
% use 'write' command to make license boot config take effect on next boot

Router(config)#end
Router#wr
Building configuration...

[OK]
Router#

Router#reload
Proceed with reload? [confirm]

Verify license status now. Following output shows that evaluation license has been activated now.

Router#show license | beg securityk9
Index 3 Feature: securityk9 
 Period left: 8 weeks 3 days 
 Period Used: 1 minute 16 seconds 
 License Type: EvalRightToUse
 License State: Active, In Use
 License Count: Non-Counted
 License Priority: Low
Index 4 Feature: ipbasek9 
 Period left: Life time
 License Type: Permanent
 License State: Active, In Use
 License Count: Non-Counted
 License Priority: Medium

Fix Hard Disk Bad Sectors in Linux

Bad Sector in a Hard Drive is a physical problem.  If bad sectors start appearing, it’s time to change the hard drive. Every OS has its own tools to scan and fix bad sectors. For example Windows has chkdsk application. Here we will discuss how to fix bad sectors in Linux.

  1. Download Ubuntu ISO and burn it on CD, DVD or a USB drive. If you have any other Linux live CD, that would also work.
  2. Boot system with the CD or USB created in step-1.
  3. Open a terminal window.
  4. Run command fdisk -l to find out the hard drive and partition device names.
  5. Type following command to run fix bad sectors application. Note: This command requires sudo privileges. Replace sda1 with the partition device name found in step-4.

            sudo e2fsck -cfpv /dev/sda1

The parameters have the following meanings: “c” searches for bad blocks and adds them to the list, “f” forces a check on the file system, “p” repairs anything that can be safely repaired and “v” is verbose mode so you can see the command progress.

This command can take a long time to run, even several hours on a particularly large drive.

Example:

ubuntu@ubuntu:~$ sudo fdisk -l
Disk /dev/loop0: 1.4 GiB, 1532116992 bytes, 2992416 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x032959e3

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 1945352191 1945350144 927.6G 83 Linux
/dev/sda2 1945354238 1953523711 8169474 3.9G 5 Extended
/dev/sda5 1945354240 1953523711 8169472 3.9G 82 Linux swap / Solaris


Disk /dev/sdb: 28.7 GiB, 30752000000 bytes, 60062500 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x05160d8f

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 60062499 60060452 28.7G c W95 FAT32 (LBA)


ubuntu@ubuntu:~$ sudo e2fsck -cfpv /dev/sda1
/dev/sda1: Updating bad block inode.

191888 inodes used (0.32%, out of 60792832)
 60 non-contiguous files (0.0%)
 194 non-contiguous directories (0.1%)
 # of inodes with ind/dind/tind blocks: 0/0/0
 Extent depth histogram: 144736/6
 4952754 blocks used (2.04%, out of 243168768)
 11 bad blocks
 1 large file

110870 regular files
 16787 directories
 55 character device files
 25 block device files
 0 fifos
 2 links
 64140 symbolic links (47056 fast symbolic links)
 2 sockets
------------
 191881 files
ubuntu@ubuntu:~$

Remove the live Linux CD or bootable USB and reboot the system.