Networxpedia

       Ø  By default, an ASA sends routing updates as RIPv1, but receives updates in either RIPv1 or RIPv2.

       Ø  If ASA has a default route and we would like it to be advertised to other RIPv2 routers, you can use the following command:

Ciscoasa(config-router)# default-information originate

       Ø  Identify any passive interface:

Ciscoasa(config-router)# passive-interface  { default | interface }

      Ø  We can filter RIPv2 routing information that is sent or received on an ASA interface by applying a distribute list.

      Ø  In a nutshell, a distribute list uses a standard IP access-list to identify specific routes; routes matching a permit statement are allowed to be used, whereas routes matching a deny statement are filtered out.

Ciscoasa(config)# access-list acl-id standard {permit|deny}  <ip-address>  <mask>

Ciscoasa(config-router)# distribute-list <acl-id> {in | out} interface <interface>

      Ø  Use RIPv2 Authentication on ASA interface:

Ciscoasa(config-if)# rip authentication mode { text | md5 }

Ciscoasa(config-if)# rip authentication key <key-string> key_id <id>

    Ø  Passive-interface command same as RIP. However, we want to interface subnet to be advertised, but don’t want the interface to participate in EIGRP routing exchanges.

     Ø  By default, EIGRP will automatically summarize subnets routes into classful network routes when they are advertised.

     Ø  But we have contiguous subnets that are separated across ASA interfaces or across EIGRP routers, we should disable route summarization with the following EIGRP command:

Ciscoasa(config-router)# no auto-summary

      Ø  If we have already disabled automatic summarization, the firewall can still advertise a summary address that is manually configured.

Ciscoasa(config-if)# summary-address  <as-num> <address> <mask> [distance]

      Ø  Redistribution:

Ciscoasa(config-router)# redistribute { rip | static | connected } [metric bandwidth delay reliability load mtu ] [ route-map map_name ]

Ciscoasa(config-router) # redistribute ospf <pid> [match {internal | external [1 | 2 ] | nssa-external [1  | 2 ] } ]  [metric  bandwidth delay reliability load mtu] [route-map map_name ]

       Ø  Use stub routing for an ASA with a single exit point.

       Ø  If the ASA has a single connection to the outside world through a neighboring router, it can become an EIGRP stub router.

       Ø  As a stub, it can receives routes (usually a default route) from its neighbor, but will advertise only specific routes of its own.

Ciscoasa(config-router)# eigrp stub {receive-only | [connected] [redistributed] [static] [summary ] }

      Ø  Authentication:

#Interface <interface>

  # authentication mode eigrp <as-num> md5

  # authentication key eigrp <as-num> <key-string> key-id <key-id>

      Ø  Use filter EIGRP updates by distribution-list

# log-adj-changes [ detail ]

      Ø  An ASA can advertise a default routes as an external route by using the following command:

Ciscoasa(config-router)# default-information originate [always] [metric value ] [metric-type { 1 | 2}]  [route-map name]

      Ø  By default, all OSPF routers have an AD of 110, we can change the distance values:

Ciscoasa(config-router)# distance ospf [ inter-area d1 ] [inter-area d2] [external d3]

      Ø  We can adjust the OSPF route calculation timers :

Ciscoasa(config-router)# timers { spf  spf_delay spf_holdtime | lsa-group-pacing seconds }

The OSPF process will wait a delay time of spf-delay (default 5 sec) after receiving a topology change before starting the SPF calculation.

OSPF will wait spf_holdtime (default 10 sec) between two consecutive calculations.

We can also tune the calculation process with the lsa-group-pacing keyword.

LSA are gathered and processed at regular intervals (the default is 240 seconds).

      Ø  Authentication OSPF neighbor in an AREA.

Ciscoasa(config-router)# area <area-id> authentication [message-digest]

# int <interface>

   # ospf message-digest-key <key-id> md5 <key>

Ciscoasa(config-router)# area <area-id> stub [no-summary]

No-summary keyword to create a totally stubby area.

      Ø  Route Filtering, If an ASA configure as an ABR, it sends type 3 LSA between the areas it touches.

      Ø  This means that the networks in each area are advertised into other areas.

      Ø  We would not want private networks to be advertised towards the outside, for security and network translation reasons., so we define a prefix-list:

Ciscoasa(config)# prefix-list <list-name> [seq seq_number] {permit | deny } prefix/len [ge min_value] [le max_value]

      Ø  Unlike RIPv2 and EIGRP, OSPF does not use a distribute-list to filter routes that are advertised, this is because every OSPF router maintains its own snapshot of the entire routing topology.

      Ø  For Example: to permit advertisement of routes with a prefix of 172.16.0.0/16, but having any mask length between 16 and 24 bits.

Ciscoasa(config)# prefix-list LIST permit 172.16.0.0/16 ge 16 le 24

      Ø  Next, apply the prefix list to filter LSAs into or out of an area with the following command:

Ciscoasa(config-router)# area <area-id> filter-list prefix <list-name> [ in | out ]

      Ø  Summarize routes between areas:

            Ø  As each packet is sent over a trunk link, it is tagged with its source VLAN number.

            Ø  As packets are removed from the trunk, the tag is examined and removed so that the packet can be   forwarded to their appropriate VLANs.

            Ø  By default, only packets that are sent out the ASA’s physical interface itself are not tagged, and they appear to use the trunk’s native VLAN.

            Ø  Packets that are sent out a sub-interface do receive a VLAN tag.

        Ciscoasa(config)# interface hardware_id.subinterface

        Ø  We have a sub-interface on the ASA that is supposed to route for the native vlan.

        Ø  When switch sends out a frame from the native VLAN, it does not tag it.

       Ø  Any VLAN setup as such will not work.

       Ø  If a packet is larger than the MTU must be fragmented before being transmitted.

       Ø  And before the packet can be presented at the destination, all of its fragments must be reassembled in their proper order.

       Ø  The fragmentation and reassembly process takes time, memory, and CPU resources, so it must be avoided if possible.

       Ø  Various IEEE standards use expanded frame sizes to carry additional information. Data centers often leverage Ethernet  “Giant”  or “jumbo” frames, which are much larger than normal, to move large amounts of data efficiently.

       Ø  We uses the command for adjust the MTU on an ASA interface:

     Ciscoasa(config)# mtu <nameif> <bytes>

       Ø  The transmitted MTU can be sized from 64 to 9216 bytes.

       Ø  We should also use the command to enable jumbo frame processing as frames are received on an interface:

Ø  The initial configuration brings up the following basic functions:

·         One interface is set as a protected “management” network, where a PC will connect.

·         A DHCP server is enabled on management network, at connected have to automatically provide an IP address to PC.

·         An HTTP server also running on management network, to allow the PC to access ASDM with the ASA via TCP port 443.

·         Management interface have IP address 192.168.1.1 and CIDR 24.

·         DHCP server allowed to provide address from a range of 192.168.1.2 to 192.168.1.254

·         HTTP server configured with subnet 192.168.1.0/24 for allow ASDM.

·         ASA’s interface 0/0  works as Management interface at initial configuration.

·         For return to factory default configuration by entering the command:

Ciscoasa(config)# configure factory-default

Ø  The configuration commands in the startup configuration are not lost after a reload or power failure.

Ø  When ASA boots, the Startup Configuration commands are copied to “running” configuration file in RAM.

Ø  ASA have Volatile RAM memory.

Ø  # show startup-config command used to see contents of the startup configuration.

Ø  We can see the running configuration content by entering the # show running-config

Ø  ASA platforms can maintain one or more startup configuration files in flash, depends on space.

Ø  Only one of these can be used at boot time.

Ø  The startup conf contents can be saved in one file during the time that the firewall configuration is stable. If major conf changes need to be made, the new, updated running configuration can be saved to a new , different startup configuration file.

Ø  The next time the ASA is booted, it can use the new startup configuration file.

Ø  If we encounter problems with the new conf, we can force the firewall to roll back or use previous startup configuration in flash memory.

Ø  We can see the startup-conf  file by command: #show startup-configuration

Ø  To force the ASA to use different startup conf file, use the command:

Ciscoasa(config)# boot config <url>

Here url represents the location of the startup configuration file. It can be

·         flash: path

·         disk0: path

2.       Clear configure primary : Clear all commands related to connectivity, including ip address, mtu , monitor-interface , boot, route, failover, tftp-server , and shun .

3.       Clear configure secondary : Clears all commands not related to ASA connectivity.

Ø  When an ASA boots, it uncompresses and copies an executable OS image from flash to RAM.

Ø  This image actually run from RAM.

Ø  While an image is being run, a different image can be copied or written into flash memory.

Ø  Contain a tree of directories, each containing arbitrary files.

Ø  ASA offers a disk0: and a flash: device. These both refer to the same internal flash memory file system.

Ø  When we connect to an ASA , our session begins in the disk0:/root directory. This directory can contain other files or sub-directories.

Ø  ASA also support a disk1: device, which is a removable flash drive.

Ø  To view the contents of a file , use command:

More [ / ascii | / binary | / ebcdic ] [ device : ] path

      Ø  By default, the file contents are shown as plain text.

      Ø  We can add the /ascii or /binary option to display both hex and ASCII represents of the file contents.

       Ø  The asa802-k8.bin image was the only valid image found at bootup time.

       Ø   The boot system disk0:/asa823-k8.bin command is then entered so that the ASA will run an upgrade  image after its next reload.

       Ø  Immediately afterward, the current BOOT variable line indicates that the new image has been identified, but will not yet be used.

       Ø  Finally, the running configuration is saved to the startup configuration.

     Ciscoasa# reload at hh:mm [ day month | month day ]

       Ø  To schedule a reload after a time interval:

     Ciscoasa# reload in { mm | hhh:mm }