UNDERSTANDING PREFIX-LISTS
Like access control lists (ACLs), prefix lists are used as a filtering tool. However, unlike ACLs, which are used for a wide variety of tasks, prefix lists are predominantly used by routing protocols for route/prefix filtering. Prefix lists provide granular control over matching prefixes for route filtering; matching the prefix and prefix-length; ACLs match only the prefix. Like an ACL, prefix-lists use permit or deny clauses to match prefixes and prefix lengths. Internal processing of IP prefix-lists uses an internal tree structure that results in faster matching of routes compared to ACLs. In recent developments, improvements have been made with the processing of prefix-lists and ACLs in hardware.
Naming and Structure
The naming and structure of prefix lists is similar to named ACLs. The prefix list naming recommendations include the following:
- Name cannot contain spaces or punctuation marks.
- Prefix list name cannot begin with a number
- Prefix list name must be unique; prefix lists of different types cannot have the same name
- Prefix list name can have a mixture alpahnumeric characters
- Recommended that the prefix list name be written in capital letters
- Prefix list names are locally significant. Multiple routers on the network can be configured to have the same name
- Choose names that identify the function of the prefix list
Prefix-lists do not use wildcard masks or bits; they use the prefix length for matching against the network address and subnet mask. A prefix-list is used to match routes particularly for route filtering and not for packet filtering:
- Permit: the route is matched, the route should not be filtered.
- Deny: route is not matched and should be filtered.
Prefix-list have a default implicit deny all statement at the end.
The command to configure a prefix-list is:
ip prefix-list <name> [seq <num>] {deny | permit}
<prefix/prefix-length> [ge <prefix-length>] [le <prefix-length>] where:
- Prefix/prefix-length: is the prefix and prefix-length that is being matched.
VRF-LITE in CISCO IOS
Virtual Routing and Forwarding Instances (VRFs) are used to segregate traffic at Layer 3. They are similar in concept to VLANs that are used to segregate traffic at Layer 2. VRFs create virtual routers with separate instances of the routing table (RIB) and forwarding table (FIB) independent from the global routing table. VRFs segment traffic in the data-plane and the control-plane based on the logical or physical interface that you assign to the VRF. The concept of VRFs is similar to that of virtual machines (VMs). It is important to note that the concept of VRF is locally significant to the device on which it is configured. VRFs improve network functionality because network paths can be segmented without requiring multiple physical routers. VRF-Lite is a feature of VRF that provides VRF without MPLS configuration.
If VRFs are configured on more than one router to ensure end to end connectivity, the links interconnecting the routers will need to be configured as a trunk (for layer 2 switches) or sub-interfaces (for routers) if a single link is to be shared with traffic from other separate VRFs or the default routing table. VRFs leverage trunk links with 802.1Q encapsulation to maintain connectivity with same VRFs on remote devices.
By default, all routers have single running VRF instance referred to as the global VRF instamce. All interfaces, the global routing table, the forwarding table are assigned to this global VRF instance. One or more VRF instances can be configured on a single router that are separate from the global routing VRF instance. The configured VRF instances can then be identified by their configured VRF names. Interfaces or sub-interfaces are then assigned to the configured VRFs. IP addresses configured on these VRF instances can overlap if the interfaces are assigned to different VRFs. These IP addreses are not included in the global routing table. If routing protocols are configured for each VRF isntance, then separate SFP (OSPF) or DUAL (EIGRP) calculation instances take place for each VRF instance.
VRFs generically segment traffic at Layer 3. However, it is possible to leak traffic between VRFs if such connectivity is required. This can be done through:
- Through importing or exporting routes between the multiple routing tables.
- Static routing.
- Physical cable to leak traffic.
Minimum configuration of VRF is called VRF Lite; VRFs without any MPLS configuration. The main reason for VRF Lite is separation of the control-plane.
The number of VRFs on a single device should be limited to a small number as each VRF instance consumes local resources.
BIDIRECTIONAL FORWARDING DETECTION (BFD)
Bidirectional Forwarding Detection (BFD) is a light-weight standards-based protocol(defined by RFC 5880) that detects failure in the forwarding path on a layer 3 network between two adjacent routers. These failures may be on the connecting interfaces, data links, tunnels, and forwarding planes of devices not directly connected to the routers in a layer 2 network. BFD is capable of working on multiple media types. BFD uses UDP packets to exchange control information with peers on port 49152 as the source port and destination port of 3784.
BFD's primary goal is to detect loss of connectivity between two devices quickly and efficiently. BFD notifies client protocols of the link failure. BFD client protocols include OSPF, IS-IS RSVP, EIGRP, HSRP, BGP, static routes that have registered to receive BFD notifications. BFD provides faster and more consistent failure detection than the hello and keepalive timers of routing protocols. Failure detection in BFD can be in the millisecond range. Most routing protocol timers will detect a link failure at a minimum of one second after it has occurred. It is up to these client protocols to determine how to recover from the failure of the link between the two devices. The client protocols may try to find alternative paths for routes that were initially accessible through the failed device. The client protocols use the BFD-provided information independently. BFD runs to serve these client protocols. It is pointless to run BFD without client protocols.
Networks carrying realtime traffic such as video and voice need speedy network convergence. Link failure detection time usually delays convergence of networks. Traditional link failure detecton relies on:
- Hello message timeouts of routing protocols.
- Transmission technology capability to detect failure.
BFD runs independent of routing protocol hellos and notifies the client protocols of link failure by sending rapid failure detection notices to routing protocols and reducing convergence time through routing table recalculation. BFD can be used in place of routing protocol timers and can act as a single method of liveliness detection between nodes irrespective of media type.
IMPLEMENTING OSPF IN CISCO IOS
OSPF is an open standard link state IP routing protocol defined by RFC 2328 (written in 1998). Another example of a link state routing protocol is Intermediate System to Intermediate System (IS-IS). Like all link state routing protocols, OSPF is a classless routing protocol that includes the subnet mask in OSPF packets exchanged between neighbors. OSPF is classified as an Interior Gateway Protocol routing within a single autonomous system. As a link state routing protocol, a router running OSPF compiles a database of all the links in the network, the OSPF routers on those links and the cost of the links. This database is the same on all routers in an OSPF area. Each router independently determines their best path to the destinations in this database. OSPF runs Dijkstra's algorithm to calculate the shortest path to any destination network in the OSPF domain. Dijkstra's algorithm is core to all link state routing alogrithms.
OSPF uses IP protocol number 89 provides its own transport layer protocol services. The current versions of OSPF are OSPFv2 that supports IPv4 and OSPFv3 that supports IPv4 and IPv6. The two versions of OSPF are not compatible i.e., routers running OSPFv3 cannot form an IPv4 adjacency with routers running OSPFv2. This entire article discusses OSPFv2.
In Cisco IOS, to configure OSPF issue the global config mode command
router ospf <process-id> where
process-id is a value between 1 - 65535:
R1#configure terminal
R1(config)#router ospf 1
IMPLEMENTING EIGRP IN CISCO IOS
Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco-proprietary enhanced distance vector routing protocol. EIGRP uses an algorithm known as diffusing update algorithm (DUAL) to identify the lowest metric network paths and provides for fast convergence using precalculated loop-free backup paths. EIGRP uses protocol-dependent modules (PDMs) to support network protocols such as IPv4 and IPv6. EIGRP is written so that the PDM is responsible for the functions that handle the route selection criteria for each network layer protocol. Current versions of EIGRP only support IPv4 and IPv6.Cisco released an informational RFC on EIGRP, RFC 7868, opening up EIGRP for implementation by other vendors. This makes it possible for EIGRP to be implemented in a multi-vendor enterprise network.
Distance vector protocols learn information about remote networks only from neighbors and therefore have a limited view of the network compared to link-state routers which learn route information from all routers in an area.
EIGRP has features unique from other distance vector protocols:
- It utilizes neighbors for sharing information and continuously monitors neighbor state
- Rapid convergence using precalculated loop-free backup paths
- EIGRP sends incremental and bounded updates; it doesn't send periodic updates; updates are only sent when there's a topology change i.e. a new network is added or an existing network is withdrawn due to link/device failure, change of path metric etc. These updates are only sent to routers that require them.
- Uses a composite metric that, by default, consists of cumulative delay and lowest path bandwidth. EIGRP can be configured to include additional parameters such as delay and reliability.
- EIGRP is the only routing protocol to-date to support unequal cost load balancing
A router can run multiple EIGRP processes. Each process operates under the context of an autonomous system, which represents a common routing domain. Routers within the same domain use the same metric calculation formula and exchange routes only with members of the same autonomous system. If there is a need/requirement for routes to be shared between different autonomous systems, then redistribution will have to be configured.
EIGRP uses IP protocol number 88. EIGRP uses both multicast and unicast to exchange the topology information. Neighbor discovery takes place through multicast packets. Once neighborships are formed, unicasts are used to synchronize the topology.
PATH CONTROL USING POLICY BASED ROUTING (PBR)
By default, routers make forwarding decisions based on the destination IP address of the packet. This is known as destination-based routing where the routing table is checked to determine next-hop IP address and the exit interface through which packets are forwarded towards the destination. In majority of network designs, destination-based routing meets designed network traffic flow. However, in some cases, some network traffic may require special treatment for instance traffic to remote corporate resources may be preferred to be routed through a specific ISP over another.
Policy-Based Routing(PBR) provides the capability to override the default destination-based routing behaviour of routing devices. PBR is implemented using a route-map to identify which unicast packets are to be policy-routed and how to route the traffic. A unicast packet arriving on a PBR-configured interface will be subject to PBR except when its destination IP address is the same as the IP address of the router's interface. Because PBR uses a route map, it provides solutions in cases where legal, contractual, or political constraints dictate that traffic is routed through specific paths.Note: PBR is only applicable to unicast packets; it is not applicable to multicast packets.
PBR makes forwarding decisions independent of the routing table. These forwarding decisions may be based upon any one or combination of the following:
- IP address i.e. destination IP address, source IP address or combination of the two.
- Protocol type i.e. IP protocols such as ICMP, TCP, UDP or TCP and UDP applications such as HTTP, FTP, SSH etc.
- Packet size: a range can be configured and packets whose sizes fall within this range can be policy routed.
- Incoming interface
- Manual assignment of different network paths to the same destination, based on tolerance for latency, link speed etc.
Some of the drawbacks of conditional routing include the following:
- Administrative burden in scalability
- Lack of network intelligence
- Troubleshooting complexity
IMPLEMENTING BORDER GATEWAY PROTOCOL (BGP)
BGP is an open standard path vector routing application based on RFC 4271. As of 2023, BGP is the only external gateway protocol in active use. BGP's primary purpose is to interconnect autonomous systems and allow the sharing of prefixes among them; Internet Service Providers (ISPs) use BGP to share prefixes. Other BGP use cases include: prefix exchange in large data centers (RFC 7938) and scaling of DMVPN where locally significant autonomous system numbers are used.
BGP forms point-to-point peerings resulting in unicast peer relationships between BGP routers. The adjacencies between BGP peers is known as BGP sessions or peering. BGP does not use hello packets to discover neighbors and due to this, BGP routers can not discover each other dynamically. Neighbor relationships need to be configured manually. BGP is able to form neighbor relationships across many hops; what is commonly referred to as a multihop relationship. This is possible because BGP uses TCP as the transport protocol. BGP updates are incremental and triggered.
BGP makes extensive use of TCP in its operations using TCP port 179 and depends on TCP reliability mechanisms for transmission of messages. TCP is responsible for:
- handling of fragmentation
- sequencing of packets
- ensuring packets are reliably transmitted
BGP provides high scalability and flexibility that does not compare to interior gateway protocols. BGP can support millions of prefixes. As of this writing, the Internet routing table size is approximately 940,000+ (Jan 2023) prefixes and counting.
Path selection is based on the multiple path attributes associated with each prefix (and not the link). Path attributes are characteristics of a prefix and include AS_PATH, local preference, multi-exit discriminator, weight and many others. Path attributes influence the best path selection process that each BGP device makes.
BGP supports the advertisement of directly connected networks, learned routes (static or from routing protocols) that exist in the RIB without the need for redistribution.
CISCO DNA CENTER ASSURANCE
Cisco DNA Center (DNAC) is the orchestration platform for designing, provisioning, and implementing policies on the network. It provides visibility into the network and an understanding of the user experience of network services. It collects telemetry from existing multiple devices, applications and users, applies advanced algorithms to uncover correlated insights and suggest remediation. This helps in minimizing troubleshooting time by identifying the root cause of issues on the network. DNAC generates health scores for client, network and applications in use; these are complied from different metrics. With Cisco DNA:
- One gains full visibility of the network
- It is possible to predict network performance and issues
- Rapidly troubleshoot issues.
The DNA Assurance landing page provides summaries of network and client health. The network health displays health summaries (in percentages) of switches, routers, wireless LAN controllers, and access points. The client health displays summaries of wireless and wired clients.
Cisco DNA includes guided remediation provides suggestions for correcting a problem
SD-Access and DNA Setup
The following discussion on Cisco DNA Center is based on version 2.2.2.8 released on 17/June/2022. Other Cisco DNA Center releases can be found here.
The DNA Center version in use can be determined by clicking the "About" icon at the top right.
SD-Access fabric, in a campus network enables the maintenance of network policies to a roaming user regardless of their location. SD-Access uses IS-IS as the underlay protocol and LIST-VXLAN+TrustSec in the overlay protocol to allow users with their devices to be onboarded onto the network and maintain their same network configuration anywhere on the network.
The SD-fabric is created by DNA center. A guided workflow is used to setup the entire SD-fabric. There are four in total. The following is a simplified sitemap of the DNA modules:
- Design: design of the physical layout of the network is developed
including the addresses of the buildings, and geographical locations. Features that
can be configured under network hierarch include:
- Network Hierarchy: create organizational hierarchies. Import and export of hierarchies is supported. The two export options are sites or maps.
- Network Settings: consists of the following:
- Network: Configure AAA, NTP and Image Distribution(SFTP) servers. Once devices are discovered, DNAC will depliy using these settings. Other settings are DNS server, message of the day(MoTD) with the option to not override the device MoTD; default is to override the device MoTD. These settings can be applied to a site or to global(all sites).
ACCESS CONTROL LISTS (ACLs)
An Access Control List (ACL) is a sequential list of rules containing permit or/and deny statements, that are used to match packets. When applied to interfaces, ACLs are used to perform a network control service. Each rule in the ACL is known as an Access Control Entry (ACE); sometimes referred to as ACL statements. Each ACE can permit or deny specific traffic. Depending on the type of ACL, each ACE contains match criteria that packets transiting the device are subjected to such as:
- Source and destination IP address
- IP protocols such as TCP, UDP, ICMP, OSPF, EIGRP etc
- TCP/UDP source and destination port numbers
The original intent when introducing ACLs was packet filtering. ACLs have since be deployed to provide multiple network functinos such as:
- Quality of Server (QoS) operations such as queueing, traffic classification for policing
- Policy-based routing (PBR)
- Route maps
- Network identification in routing protocols
- Route modification/filtering
- Management plane restrictions such as Telnet, SSH, VPN
- Object tracking
Types of ACLs
There are several types of ACLs:
The ACLs that are discussed in this post are: standard ACLs, extended ACLs, time-based ACLs, reflexive ACLs, and Dynamic ACLs.
CONFIGURING LOGGING
Logging can be used for fault identification, security auditing and network forensics. Logging aims to answer the three questions: what, when, who? Log messages are generated by the various services and protocols running on a network device. By default, output from system messages and debug commands is sent to a logging process. The logging process controls the distribution of logging messages to various destinations, such as the logging buffer, terminal lines, syslog server. Messages are also sent to the console. These are then viewed using syslog, local logging, debugs, conditional debugs. Logs are also used for forensics and compliance. It is important to note that the time must be consistent. This can be done by configuring NTP to provide accurate datetime values. Troubleshooting can be difficult if you cannot correlate timestamps across devices.
Logging Messages
Syslog messages can be output to the console, local buffer or remote syslog server. The messages follow this format:
%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: message text
Where:
- FACILITY-SUBFACILITY: protocol, module or process that generated the message.
- SEVERITY: This is a level from 0 - 7 that specifies how important
the message is. When you enable logging for a specific level, it also enables
all levels above it. For example, if you enable level 4(warnings), it also will
enable levels 0 - 3.
Level Number Severity Description Syslog Definition 0 Emergencies System is unusable LOG_EMERG 1 Alerts Action must be taken immediately LOG_ALERT 2 Critical Critical conditions LOG_CRIT 3 Errors Error conditions LOG_ERR 4 Warnings Warning conditions LOG_WARNING 5 Notifications Normal but significant conditions LOG_NOTICE 6 Informational informational messages LOG_INFO 7 Debugging debug-level messages LOG_DEBUG - MNEMONIC: a code that identifies the action reported
- Message text: A plain text description of the event
Local Logging
By default, all logging is displayed on the console. This can be turned off with
the no logging command.
By default, monitor and buffer logging display messages with severity
levels of debugging and lower.
For SSH/Telnet, the logging session settings can be configured using the command
terminal monitor
Logging Console
To enable logging to console, use the command
logging console. By default, the logging severity level for console is
debugging. To control the logging options, use the command logging console <level>.
Logging Buffer
For local logging, Cisco IOS can save syslog messages to an internal buffer i.e.,
all the logs are saved on the device itself. You
can display these messages by using the show logging command.
These messages are lost when the device is rebooted. The default buffer size is
8192 bytes. When the buffer is full, the older logs get overwritten by the newer ones.
The size of the buffer can be increased using the command:
logging buffered <size>.
CONFIGURING SNMPv2c and SNMPv3
SNMP is an open standard protocol for collecting and modifying information about managed devices on IP networks. SNMP is an application layer protocol that supports message exchange in a specific format between SNMP managers and agents. It is used for monitoring and managing devices on a network. SNMP is able to retrieve data, modify SNMP object variables of managed devices on IP networks and send notifications to Network Management Stations (NMS). Some devices that support SNMP include routers, switches, servers, workstations, printers etc.
SNMP components include; SNMP manager (NMS), SNMP agent and SNMP MIB.
- SNMP manager: controls and monitors the operation of network hosts using SNMP. The manager receives unsolicited notifications from agents running on monitored devices. Additionally, the manager polls SNMP agents running on the network devices for information. The manager runs as software on a computer/server.
- SNMP Agent: is a software component that runs on the managed device. It collects and stores information on the device. The agent responds to manager requests for information. The agent can send the manager unsolicited notifications (traps or informs) to notify the manager about conditions on the managed device.
- MIB: is a database of objects (information variables) that lists various attributes of the managed device that can be monitored. An SNMP agent contains MIB variables, whose values the SNMP manager can request for or change through the Get or Set operations. A manager can retrieve a value from an agent or store a value from that agent. The agent gathers data from the SNMP MIB. The MIB uses read and write community strings for controlling access. Object Identifier (OID) is an ID for the various components in the MIB of a managed device.
SNMP operations involve SNMP agents running on the managed devices sending monitoring data to the SNMP manager. SNMP uses the following operations to retrieve and modify objects on managed/monitored devices:
- SNMP Get: A Get operation is performed by the SNMP manager to retrieve SNMP object
variables from the agent. There are three types of GET operations;
- Get: Retrieves exact object instance identified by OID or name.
- GetNext: Retrieves next object variable (successor) to the specified variable.
- GetBulk: Retrieves large amount of object variable data without repeated GetNext operations.
- SNMP Set: An NMS carries out a SET operation to modify the value of the object variable on a managed device.
- SNMP Notifications: Traps and informs are unsolicited (asynchronous) notifications sent by an agent to an NMS.
Traps, Informs, and Polls
Traps are unsolicited messages alerting the NMS to a condition on the managed device. Traps are discarded as soon as they are sent. Traps are sent once and do not require acknowledgement by the manager.
Informs are traps that include a request for confirmation of receipt from the SNMP manager. The SNMP manager sends a confirmation using SNMP response PDU. If the Agent did not receive a response for an inform, the inform can be sent again. Informs may be sent many times hence traps are usually preferred. An inform is held in memory until a response is received or times out. Traps are usually preferred because they consume less resources than informs which are held in memory until a response is received.
Polls are probes where the SNMP manager sends an SNMP request to the agent and receives an SNMP reply to this request. The SNMP GetRequest(poll) is sent using UDP port 161 and the SNMP GetResponse(trap) sent using UDP port 162.
IMPLEMENTING NetFlow v5, v9, Flexible NetFlow
Netflow is a Cisco application that collects statistics on packets flowing through a router. By analyzing the data provided by NetFlow, a network administrator can determine the characteristics of network traffic such as source, destination of traffic, class of service to get a hint on troubleshooting network problems such as the causes of congestion. NetFlow provides insights into the state of network traffic and this information can be utilized in network and security monitoring, network planning, traffic analysis, application monitoring, capacity planning, and IP accounting. Most NetFlow devices support export versions 1, 5, and 9 though version 1 is used by default.
Netflow provides the ability to view network traffic grouped by protocol. With this feature, a baseline of network traffic can be performed before the introduction of a new network service or implementation of traffic shaping.
For Internet-facing routers that run NAT, it is recommended that Netflow be configured on the router interface connecting to the local network i.e. before NAT translations. If Netflow is configured on the Internet-facing interface, NAT will have been implemented and it becomes difficult to understand traffic flow patterns of local devices as their local/internal IP addresses will already have been translated by NAT.
A typical flow monitoring setup using NetFlow consists of three main components:
- Flow exporter: aggregates packet data into flows and exports flow records to one or more flow collectors. This is usually a router.
- Flow collector: responsible for reception, storage and processing of flow data received from a flow exporter.
- NetFlow cache: the record for each active flow is maintained locally in the cache.
A network flow is a unidirectional stream of packets between a given source and destination. A flow is uniquely identified by the following characteristics:
- Source IP address
- Source port number
- Destination IP address
- Destination port number
- Layer 3 protocol type
- Type of service (TOS)
- Logical input interface: router or switch interface
Traffic monitored by Netflow can be classified into the following categories:
- Device: flow count, traffic and volume
- Interface: bandwidth utilization, traffic, packets, and volume.
- Application: traffic with port and protocol details.
- Conversation: source, destination, application, and traffic
- Quality of Server(QoS): DSCP and traffic.
UNDERSTANDING ADMINISTRATIVE DISTANCE
Administrative Distance (AD) is a ranking of believability or trustworthiness of a routing information source. A router uses the routing information base (RIB) also known as routing table, to determine how to route traffic to destination networks Routing information sources inform the router about paths to various networks. Administrative distance is the first criterion that a router uses when making a path selection decision if two or more routing information sources provide route information for the same destination network. If a router learns about the path to a prefix from different sources such as: OSPF, EIGRP, BGP, static routes, routers use AD assigned to each of those sources to decide which source of routing information should be installed into the routing table and therefore used for routing traffic. The AD is a value that ranges from 1 to 255. The lower the AD of a route source, the more believable its routing information and more likely that its offered routes will be installed into the routing table. Routes with an AD of 255 are not installed in the routing table as they are considered unbelievable. The router will install into the routing table the route from the source with the lowest AD. Each path installed in the routing table has an Administrative Distance. The AD of a route in the RIB indicates that the route was installed from a given source.
In many networks, only one routing protocol is operational. Some scenarios exist where two or more dynamic routing protocols are configured in a network simultaneously such as during a routing protocol migration where one layer three routing protocol is being replaced by another. This results in routing devices in the network receiving routing information from various sources.
Default Administrative Distance
Cisco IOS assigns different ADs to all supported routing information sources. The default AD of the various routing information sources is shown in the following table:
| Route Source | Default Administrative Distance |
| Connected interface | 0 |
| Static route | 1 |
| Enhanced Interior Gateway Routing Protocol (EIGRP) summary route | 5 |
| External Border Gateway Protocol (eBGP) | 20 |
| Internal EIGRP | 90 |
| IGRP | 100 |
| OSPF | 110 |
| Intermediate System-to-Intermediate System (IS-IS) | 115 |
| Routing Information Protocol (RIP) | 120 |
| Exterior Gateway Protocol (EGP) | 140 |
| On Demand Routing (ODR) | 160 |
| External EIGRP | 170 |
| Internal BGP (iBGP) | 200 |
| Unknown* | 255 |
* A route with an administrative distance of 255 will not be installed in the routing table.
The default AD can be modified to implement traffic shaping where traffic follows specific routes according to the design of the network.
Note: AD is used in path selection only if the destination prefix is the same for routes from various routing information sources. In situations where the subnet mask is different, the routing information source with the more specific path will always be used regardless of the AD.
UNICAST REVERSE PATH FORWARDING (uRPF)
Unicast Reverse Path Forwarding (uRPF) is used to limit malicious traffic in a network by blocking packets transiting a router having unknown source IP addresses. The design intention of uRPF is to block IP packets with spoofed or malformed source IP addresses. It does this by checking the source IP address of packets arriving on an interface and determining whether the network of the source IP address is reachable using Layer 2 information in the Forwarding Information Base (FIB). The FIB is generated by Cisco Express Forwarding (CEF). If the network of the packet source IP address is not reachable, the packet is dropped.
When forwarding traffic, by default, routers checks for the reachability of a destination
IP address prior to forwarding IP packets. With uRPF, the router validates reachability
of the source IP address as well. uRPF can also be configured to verify whether the
interface through which the packets entering the router is what the router would
normally use to send traffic back to IP addresses in that network.
For uRPF to function, CEF must be enabled globally (using the global configuration
command ip cef).
How uRPF Works
The uRPF feature helps to mitigate problems caused by the introduction of malformed or forged/spoofed IP source addresses into a network by discarding IP packets that lack a verifiable IP source address. A number of common Denial-of-Service (DoS) attacks such as smurf attacks, tribal Flood Network (TFN) attacks take advantage of forged or rapidly changing source IP addresses.
uRPF depends on CEF being enabled because the lookup relies on the FIB which is generated by CEF. uRPF is an input function and is applied only on the input interface of a router at the upstream end of a connection.
uRPF checks to see if any packet received at a router interface arrives on the best return path to the source of the packet. uRPF does this by carrying out a reverse lookup in the CEF table. If the packet is received from one of the reverse path routes, the packet is forwarded as normal.
If a reverse path for the packet is not found, the packet is dropped or forwarded depending on whether an ACL is specified in the URF configuration.
With uRPF, all equal cost return paths are considered valid. uRPF works in cases where multiple return paths exist provided that each path is equal to others in terms of routing cost, i.e. number of hops, weight etc.and as long as the route is in the FIB. uRPF also functions where EIGRP variants are being used with unequal cost routes back to the packet source IP address.
CONTROL PLANE POLICING (CoPP)
CoPP is a QoS feature used in security that rate-limits the traffic handled by the route processor(RP). CoPP a modular QoS CLI(MQC) policy to rate-limit, drop and granularly permit traffic to or from the RP. The RP handles traffic that is categorized into three planes:
- Data plane
- Management plane
- Control plane
The control plane is a collection of processes that run at the process level on the route processor(RP). These processes collectively provide high-level control for most IOS functions. All packets destined for the control plane pass through the central switch engine before they are forwarded to the process level. The control-plane and central switch engine are part of the RP.
Majority of traffic managed by the RP is handled by way of the control and management planes. Such traffic includes;
- Routing protocol updates (IGP, BGP)
- Management traffic such as SNMP, SSH,Telnet, NTP, HTTP(S), etc.
- Traffic destined for a local IP address of the switch/router where the local router or switch is the destination of the traffic.
Control-plane Policing (CoPP) provides rate-limiting and filtering capabilites to control the number of packets that have to be processed by the RP of a router or switch. This helps in reducing the load on a router’s RP at any given point in time. It helps protect the RP from denial-of-service(DoS) attacks, and other flooding attacks, reconnaisance attacks.
In CoPP, it is important to rate-limit traffic on all interfaces destined for the local router. A logical interface exists on all routers called the control plane interface. Rate-limiting packets on this interface applies the rate-limit to all the physical interfaces that need to be processed by the RP. Quality of Service (QoS) and policing on the control plane interface rate-limits packets entering any interface to protect the RP.
Configuring CoPP
CoPP is hardware-accelerated if the command mls qos is
applied.
To implement CoPP, the following sequence of steps should be followed:
- Categorize network traffic into classes and apply the categorization using an Access Control List (ACL).
- Create a Class Map (CM) to identify traffic to be policed (rate-limited).
- Create a Policy Map (PM) to define the action to take on identified traffic by implementing a defined policy.
- Create a Service Policy which specifies where to apply the policy map
IPv6 FIRST HOP SECURITY
As IPv4 public addresses get depleted, the number of IPv6 deployments has increased exponentially. This exponential increase in the adoption of IPv6 can also be attributed to introduction of Internet of Things (IoT).
With all these devices gaining access to networks, security concerns are growing in IPv6 deployments. It is important that these IPv6 deployments are secured for optimum operation of these networks. A critical part of the network that needs to be considered when implementing security mechanisms is at the local links (Layer 2) where hosts are connected to the network.
First hop is the network segment between the end hosts and their default gateway i.e., the access layer. Security at the first hop aims to prevent against internal threats at the access layer such as a man-in-the-middle(MiM) attack. In IPv4, security at the access layer is implemented through DHCP snooping, IP source guard and dynamic ARP inspection. Most IPv6 first-hop security features are implemented on a layer 2 device(switch).
In IPv6, ICMPv6 ND/NDP replaces IPv4 ARP. ARP uses two messages: request and reply. With ICMPv6 ND uses four messages:
- Neighbor Solicitation(NS): a device requests for information about a neighbor.
- Neighbor Advertisement(NA): a device advertises its information to other neighbors.
- Router Solicitation(RS): a device requests for information about local routers i.e., routers in the network segment.
- Router Advertisement(RA): a device advertises itself as an active router.
When a host is added to a network:
- The host chooses a link-local address; usually FE80::/10 for the network segment of the address. The host segment of the address is generated using EUI-64.
- The host then checks to confirm that the link-local address is unique by sending an NS on the local link to the solicited node multicast address(FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits from the EUI-64). If no response is received for the NS, then the link-local address is confirmed as unique.
- The host then sends a NA to the "all hosts multicast address" FF02::1 (similar to 255.255.255.255 in IPv4) announcing itself as a host.
- Router discovery is then attempted by sending RS messages to FF02::2 (all routers multicast address).
- A local router replies with RA that contains the router's IPv6 address and MAC address along with prefix information for SLAAC.
- The host chooses a global prefix for SLAAC where the address is generated using the RA advertised prefix and EUI-64 for the host part of the address. The host performs DAD to verify that the global prefix address is unique. If unique, the host sends a NA for the global prefix.
DEVICE SECURITY USING AAA (TACACS+, RADIUS and Local Database)
Privileges
Privileges are the list of commands that a user is authorized to execute. Cisco defines different privilege levels with level 0, 1 and 15 reversed. Privilege levels 2-14 are open for customization. The following table displays the different levels of privileges in Cisco IOS:
| Privilege Level | Origin | Accessibility |
| 0 | Built-in | No access. Few commands are available. |
| 1 | Built-in | User mode, very limited access. It is the default exec user level and provides some show commands. |
| 15 | Built-in | Privilege exec / enable mode, verification and full access. |
| 2 - 14 | User-defined | Granular control over commands users are authorised to use |
Custom Privileges
These custom privilege levels are defined in the range 2 – 14. Users can then be assigned these privileges based on the level of configuration depth that you would like them to make on the devices. The default privilege for remote access (SSH, Telnet) is 1(one) while console is 15. If a privilege level is not assigned to a line or user, then the default privilege is used.
When configuring allowable commands to privilege levels, higher privilege levels inherit commands allowed in lower privilege levels. For example assigning a privilege level of 7 to a user allows the user to run commands that have been allowed to be run in privilege levels 0 – 6 in addition to level 7.
The following example configuration sets the commands that the custom privilege level 2 is permitted to run. Here, the user is permitted to access the configuration mode and shutdown or enable interfaces only. Privilege level 2 is then assigned to a user account on the local database.
R1(config)#privilege exec level 2 configure terminal
R1(config)#privilege configure level 2 interface
R1(config)#privilege interface level 2 shutdown
R1(config)#privilege interface level 2 no shutdown
R1(config)#privilege exec level 2 show privilege
R1(config)#username bob privilege 2 secret alice
When the privilege level is defined on the router as in the case above, by default, the router will use the local database for commands.
The use of role-based access control(RBAC) provides granular control over commands and privileges from a centralized point.
No comments:
Post a Comment