TS5 IGP ticket

OSPF area types

Advancing from last week's discussion on OSPF network types, today's topic is a source of considerable confusion for many people new to OSPF: area types. Recall that a large OSPF domain is typically broken into separate areas to restrict the propagation of routes and reduce the amount of resources required by each router to maintain its link state database. Each area is connected to a central backbone, area zero.

OSPF relies on several types of Link State Advertisements (LSAs) to communicate link state information between neighbors. A brief review of the most applicable LSA types:

·         Type 1 - Represents a router
·         Type 2 - Represents the pseudonode (designated router) for a multiaccess link
·         Type 3 - A network link summary (internal route)
·         Type 4 - Represents an ASBR
·         Type 5 - A route external to the OSPF domain
·         Type 7 - Used in stub areas in place of a type 5 LSA

LSA types 1 and 2 are found in all areas, and are never flooded outside of an area. Whether the other types of LSAs are advertised within an area depends on the area type, and there are many:

·         Backbone area (area 0)
·         Standard area
·         Stub area
·         Totally stubby area
·         Not-so-stubby area (NSSA)

Let's begin by examining a standard area. Note that the backbone area is essentially a standard area which has been designated as the central point to which all other areas connect, so a discussion of standard area behavior largely applies to the backbone area as well.

Standard Areas

In the example above, router 2 acts as the area border router (ABR) between a standard area and the backbone. R3 is redistributing routes from an external domain, and is therefore designated as an autonomous system boundary router (ASBR).
As mentioned, type 1 and 2 LSAs are being flooded between routers sharing a common area. This applies to all area types, as these LSAs are used to build an area's shortest-path tree, and consequently only relevant to a single area. Type 3 and 5 LSAs, which describe internal and external IP routes, respectively, are flooded throughout the backbone and all standard areas. External routes are generated by an ASBR, while internal routes can be generated by any OSPF router.
Note the peculiar case of type 4 LSAs. These LSAs are injected into the backbone by the ABR of an area which contains an ASBR. This is to ensure all other routers in the OSPF domain can reach the ASBR.
Standard areas work fine and ensure optimal routing since all routers know about all routes. However, there are often situations when an area has limited access to the rest of the network, and maintaining a full link state database is unnecessary. Additionally, an area may contain low-end routers incapable of maintaining a full database for a large OSPF network. Such areas can be configured to block certain LSA types and become lightweight stub areas.

Stub Areas

In this next example, R2 and R3 share a common stub area. Instead of propagating external routes (type 5 LSAs) into the area, the ABR injects a type 3 LSA containing a default route into the stub area. This ensures that routers in the stub area will be able to route traffic to external destinations without having to maintain all of the individual external routes. Because external routes are not received by the stub area, ABRs also do not forward type 4 LSAs from other areas into the stub.
For an area to become a stub, all routers belonging to it must be configured to operate as such. Stub routers and non-stub routers will not form adjacencies.

Router(config-router)# area 10 stub

This idea of substituting a single default route for many specific routes can be applied to internal routes as well, which is the case of totally stubby areas.

Totally Stubby Areas

Like stub areas, totally stubby areas do not receive type 4 or 5 LSAs from their ABRs. However, they also do not receive type 3 LSAs; all routing out of the area relies on the single default route injected by the ABR.
A stub area is extended to a totally stubby area by configuring all of its ABRs with the no-summary parameter:

Router(config-router)# area 10 stub no-summary

Stub and totally stubby areas can certainly be convenient to reduce the resource utilization of routers in portions of the network not requiring full routing knowledge. However, neither type can contain an ASBR, as type 4 and 5 LSAs are not permitted inside the area. To solve this problem, and in what is arguably the worst naming decision ever made, Cisco introduced the concept of a not-so-stubby area (NSSA).

Not-so-stubby Areas

An NSSA makes use of type 7 LSAs, which are essentially type 5 LSAs in disguise. This allows an ASBR to advertise external links to an ABR, which converts the type 7 LSAs into type 5 before flooding them to the rest of the OSPF domain.
An NSSA can function as either a stub or totally stubby area. To designate a normal (stub) NSSA, all routers in the area must be so configured:

Router(config-router)# area 10 nssa

Type 3 LSAs will pass into and out of the area. Unlike a normal stub area, the ABR will not inject a default route into an NSSA unless explicitly configured to do so. As traffic cannot be routed to external destinations without a default route, you'll probably want to include one by appending default-information-originate (thanks to Adam for pointing this out).

Router(config-router)# area 10 nssa default-information-originate

To expand an NSSA to function as a totally stubby area, eliminating type 3 LSAs, all of its ABRs must be configured with the no-summary parameter:

Router(config-router)# area 10 nssa no-summary

The ABR of a totally stubby NSSA (or not-so-totally-stubby area, if you prefer) injects a default route without any further configuration.

Summary

• Standard areas can contain LSAs of type 1, 2, 3, 4, and 5, and may contain an ASBR. The backbone is considered a standard area.
• Stub areas can contain type 1, 2, and 3 LSAs. A default route is substituted for external routes.
• Totally stubby areas can only contain type 1 and 2 LSAs, and a single type 3 LSA. The type 3 LSA describes a default route, substituted for all external and inter-area routes.
• Not-so-stubby areas implement stub or totally stubby functionality yet contain an ASBR. Type 7 LSAs generated by the ASBR are converted to type 5 by ABRs to be flooded to the rest of the OSPF domain.

ZONE BASE FIREWALL

ZONE BASE FIREWALL

A security zone should be configured for each region of relative security within the network, so that all interfaces that are assigned to the same zone will be protected with a similar level of security. For example, consider an access router with three interfaces:

• One interface connected to the public Internet
• One interface connected to a private LAN that must not be accessible from the public Internet
• One interface connected to an Internet service demilitarized zone (DMZ), where a Web server, Domain Name System (DNS) server, and e-mail server must be accessible to the public Internet

Each interface in this network will be assigned to its own zone, although you might want to allow varied access from the public Internet to specific hosts in the DMZ and varied application use policies for hosts in the protected LAN. (See Figure 1.)

 

In this example, each zone holds only one interface. If an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone. Additionally, the hosts’ traffic to hosts in other zones is similarly affected by existing policies.
Typically, the example network will have three main policies:

• Private zone connectivity to the Internet
• Private zone connectivity to DMZ hosts
• Internet zone connectivity to DMZ hosts

Because the DMZ is exposed to the public Internet, the DMZ hosts might be subjected to undesired activity from malicious individuals who might succeed at compromising one or more DMZ hosts. If no access policy is provided for DMZ hosts to reach either private zone hosts or Internet zone hosts, then the individuals who compromised the DMZ hosts cannot use the DMZ hosts to carry out further attack against private or Internet hosts. ZFW imposes a prohibitive default security posture. Therefore, unless the DMZ hosts are specifically provided access to other networks, other networks are safeguarded against any connections from the DMZ hosts. Similarly, no access is provided for Internet hosts to access the private zone hosts, so private zone hosts are safe from unwanted access by Internet hosts.


Cisco Policy Language (CPL) Configuration
This procedure can be used to configure a ZFW. The sequence of steps is not important, but some events must be completed in order. For instance, you must configure a class-map before you assign a class-map to a policy-map. Similarly, you cannot assign a policy-map to a zone-pair until you have configured the policy. If you try to configure a section that relies on another portion of the configuration that you have not configured, the router responds with an error message.

1. Define zones.
2. Define zone-pairs.
3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair.
4. Define policy-maps to apply action to your class-maps’ traffic.
5. Apply policy-maps to zone-pairs.
6. Assign interfaces to zones.

Configuring Zone-Based Policy Firewall Policy-Maps
The policy-map applies firewall policy actions to one or more class-maps to define the service-policy that will be applied to a security zone-pair. When an inspect-type policy-map is created, a default class named class class-default is applied at the end of the class. The class class-default’s default policy action is drop, but can be changed to pass. The log option can be added with the drop action. Inspect cannot be applied on class class-default.

Zone-Based Policy Firewall Actions

ZFW provides three actions for traffic that traverses from one zone to another:

• Drop—This is the default action for all traffic, as applied by the "class class-default" that terminates every inspect-type policy-map. Other class-maps within a policy-map can also be configured to drop unwanted traffic. Traffic that is handled by the drop action is "silently" dropped (i.e., no notification of the drop is sent to the relevant end-host) by the ZFW, as opposed to an ACL's behavior of sending an ICMP “host unreachable” message to the host that sent the denied traffic. Currently, there is not an option to change the "silent drop" behavior. The log option can be added with drop for syslog notification that traffic was dropped by the firewall.


• Pass—This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections or sessions within the traffic. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is useful for protocols such as IPSec ESP, IPSec AH, ISAKMP, and other inherently secure protocols with predictable behavior. However, most application traffic is better handled in the ZFW with the inspect action. 


• Inspect—The inspect action offers state-based traffic control. For example, if traffic from the private zone to the Internet zone in the earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router permits return traffic sent from Internet-zone hosts in reply to private zone connection requests. Also, inspect can provide application inspection and control for certain service protocols that might carry vulnerable or sensitive application traffic. Audit-trail can be applied with a parameter-map to record connection/session start, stop, duration, the data volume transferred, and source and destination addresses

Virtual link

IP PRECEDENCE 6 FOR ROUTING PROTOCOL

This table lists the values of the precedence bits:

Number	Bit Value	Name
0	000	Routine
1	001	Priority
2	010	Immediate
3	011	Flash
4	100	Flash Override
5	101	CRITIC/ECP
6	110	Internetwork Control
7	111	Network Control

   Cisco IOS assigns an IP precedence of 6 to routing protocol packets on the control plane. As noted by RFC 791, "The Internetwork Control designation is intended for use by gateway control originators only." Specifically, Cisco IOS marks these IP-based control packets: Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP) hellos, and keepalives. Telnet packets to and from the router also receive an IP precedence value of 6. The assigned value remains with the packets when the output interface transmits them into the network.

TS5