Applying Routing Protocols
Routing protocols are used to distribute IP forwarding information throughout a network, it acts much like a map given to all devices on a network. Without having a map and knowing the next hop toward a specific subnet there would be no way to access different systems around the network.
The importance of IP routing protocols in discussed in the CCNP Enterprise certifications, so you may be asking why are routing protocols a part of the Data Center track? The answer is pretty simple: CCNP Enterprise deal is Cisco IOS and IOS-XE images that are applied to routers and switches; the CCNP Data Center we are talking about devices running the NX-OS, as in the the of the devices the Nexus Operating system.
The Nexus operating system acts much like the IOS-XE versions but in certain cases there are specific differences in how the technologies and protocols are configured or enabled, as an example you have to turn on the eigrp, ospf, or hsrp features before you can use those features.
Nexus switches support all of the major routing protocols: EIGRP, OSPF, IS-IS, BGP, static routing, and RIP. The CCNP Data Center Core only covers OSPF & BGP dynamic routing protocols for some reason, but you should also be aware of EIGRP for the Advanced Enterprise Routing.
Open Shortest Path First is a Link-State routing protocol that uses areas to separate and break up the Link State Database by creating network summaries, you can check out the RFCs on OSPF by checking out OSPFv2 RFC2328 and OSPFv3 RFC5340. OSPF, unlike EIGRP, works by using areas and process IDs, EIGRP on the other hand uses autonomous systems (oddly enough EIGRP is not a part of the CCNP Data Center DCCOR). You can have multiple OSPF processes on a network device and multiple areas within each process.
To enable a routing protocol you need to enable its feature - feature ospf & feature ospfv3.
To remove the feature you just use the no option - no feature ospf, keep in mind that when you remove a feature NX-OS will remove all of the corresponding ospf configuration. One nice thing about NX-OS is that when you remove a feature the system will create a checkpoint giving you the ability to roll back the configuration if the removal of the feature was an accident and you need to revert.
OSPF works a bit differently in NX-OS than in IOS, you enable OSPF on an interface rather than using the legacy network statements used to specify multiple network interfaces, keep in mind that the network statement still exists under the OSPF routing protocol process configuration but will not show up using the ? or tab elements.
OSPFv2 configuration example:
configure terminal
feature ospf
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
auto-cost reference-bandwidth 10 Gbps
interface Ethernet0/0
ip router ospf area 0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 password OSPF_authentication_string
What do all these commands do?
feature ospf
The feature command enables that technology to be used within the Nexus Operating System, feature ospf will enable OSPFv2
router ospf process-id
This command enables the OSPF process and creates the OSPF instance for the process number specified, it will then open the global configuration for OSPFv2
router-id IPv4 style address
Each device in the OSPF system requires a router-id to be generated or configured manually, the router-id has multiple uses: such as identifying the OSPF router, you use the router-id to configure virtual-links, etc.
log-adjacency-changes
Whenever a neighbor adjacency changes this command will generate a syslog message stating the change, this option is good because you can use an EEM or syslog response by sending notifications to administrators so they can act on the why the adjacency changed.
auto-cost reference-bandwidth number Gbps
The default auto-cost reference of OSPF 40Gbps on the newer NX-OS images, originally the auto-cost reference in IOS used to be 10^8 or 100,000,000 or 100Mbps.
When OSPFv2 came out back in 1989 as RFC 1131, 100Mbps was fast enough to handle properly configuration the metric of routes in a network, when bandwidth exceeded 100Mbps all metrics would equate to 1 so if you had links utilizing 1Gbps, 2.5Gbps, 5Gbps, 10Gbps, 25Gbps, 40Gbps, 100Gbps they are came out as 1, by changing the default auto-cost reference bandwidth to 40Gbps these metrics were calculated properly:
| Bandwidth | 100 | 1 | 10 | 25 | *40 | 100 |
| 10Mbps | 10 | 100 | 1000 | 2500 | 4000 | 10000 |
| 100Mbps | 1 | 10 | 100 | 250 | 400 | 1000 |
| 1Gbps | 1 | 1 | 10 | 25 | 40 | 100 |
| 10Gbps | 1 | 1 | 1 | 2.5 | 4 | 10 |
| 25Gbps | 1 | 1 | 1 | 1 | 1.6 | 4 |
| 40Mbps | 1 | 1 | 1 | 1 | 1 | 2.5 |
ip router ospf 1 area 0
This command enables OSPFv2 on the interface using the process number 1 and places it in area 0.
ip ospf authentication message-digest
OSPFv2 can use both clear-text and message-digest based authentication, this command tells OSPFv2 that authentication will be used and that it's a message-digest hash.
ip ospf message-digest-key 1 md5 password
After enabling OSPFv2 authentication and specifying message-digest you must provide a pre-shared-key, this key is sent to other potential OSPFv2 neighbors to authenticate them as true neighbors before an adjacency can be made.
OSPFv3 configuration example:
configure terminal
feature ospfv3
router ospfv3 1
router-id 1.1.1.1
log-adjacency-changes
auto-cost reference-bandwidth 10 Gbps
interface Ethernet0/0
ip router ospfv3 area 0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 password OSPF_authentication_string
As you can see the basic configurations for OSPFv2 and OSPFv3 are almost identical, the only difference here is that you must specify ospfv3 rather than simply ospf, that is the distinguisher between the two.
As for differences between OSPFv2 & OSPFv3, OSPFv3 gives us the ability to use IPv6 as OSPFv2 does not support IPv6. OSPFv3 also gives us the ability to use address-families where you can specify specific configurations between the different address-families: IPv4, IPv6, Multicast.
One of the enhancements done for routing protocols has been the idea of Graceful Restart; a graceful-restart-capable device notifies its neighbors that a restart is taking place during a supervisor switchover or stateless process restart. After an initial graceful restart the device requests that the neighbor send state information to rebuild the routing tables. A graceful restart message does not reset the neighborship, after the neighborship is re-established, the neighbors begin to resynchronize their databases.
| Series of Switch | Static Router | OSPF | BGP |
|---|---|---|---|
| 9000 | No License | Enterprise Services | Enterprise Services |
| 7000 | No License | Enterprise Services | Enterprise Services |
| 5000 | Layer 3 Base | Lyaer 3 Base | Layer 3 Enterprise |
| 3000 | Layer 3 Base | Layer 3 Base (limited routes) Layer 3 Enterprise (unlimited routes) |
Layer 3 Enterprise |
OSPF uses the concept of areas in order to limit the amount of information stored in the tables and database of OSPF.
OSPF utilizes the Link-State Database in order to contain all of the devices and routes available within it's system, unlike EIGRP that only looks at next-hop information, OSPF shares and keeps a database of all systems in the OSPF area that can get quite huge. For OSPF each device has a copy of the entire routing domain stored, so it has a picture of the entire area.
Breaking OSPF up into multiple areas allows for summarization and a smaller LSDB, limiting the amount of devices needing to see the whole picture is process and hardware efficient when there is no need to have all devices with the whole picture.
All areas MUST connect to the backbone area: Area 0 - if an area doesn't connect back to area 0 you will have errors and OSPF might not run as expected.
If you have an area that needs to exist but it doesn't connect directly to area 0 you either have to re-design your network so that it does or you can create what's called a "virtual-link" that basically creates a tunnel between the connected area as a transit back to area 0, keep in mind that the virtual-link uses the router-id to create its connectivity so if you were wondering the reasoning behind the router-id here's one of them.
OSPF messages
OSPF uses Link-State Advertisements, Link-State Updates to provide information to there neighbors to provide a full-view of the network:
LSA Type:
Type 1 - Router LSA
The Router LSA is flooded by the OSPF router to all other OSPF routers within a segment to advertise the link
Type 2 - Network LSA
The Network LSA is generated by all multi access networks by the Designated Router, DR, to advertise to all routers connected on that multiaccess link as well as the network and its prefix.
Type 3 - Summary LSA
When you have multiple areas the summary LSA is advertised be the Area Border Router, ABR, to flood all prefix information throughout the autonomous system. Don't be confused by the name though, Type 3 LSAs don't actually summarize any routes, it's meant to bring Inter Area routes to and from the backbone area into others. When looking at the routing table the summary LSA will be displayed as O IA or the OSPF InterArea prefix route.
Type 4 - Summary ASBR LSA
When you have multiple autonomous systems or an internet-like exit the device that connects the two are known as an Autonomous System Boundary Router, the type 4 LSA basically tells the backbone that it exists. The ASBR will flip a bit in its type 1 router LSA to distinguish itself as an ASBR, the next hop ABR will then generate the type 4 Summary ASBR to tell area 0 that it has a connection to another AS.
Type 5 - Autonomous System External LSA
Any network reachability shared from an AS into OSPF through the ASBR will be described as Type 5, these routes will be labeled as O E1 or O E2. When dealing with ASBR and NSSA router you will see a 1 or a 2; O E1, O E2, O N1, O N2. E1 includes the internal cost to ASBR added to the external cost, E2 does not include internal cost.
Type 6 - Multicast OSPF LSA
Type 7 - Not-So-Stubby LSA
Type 8 - External Attribute LSA
Network types:
BMA - Broadcast Multiple Access ip ospf network-type broadcast
NMBA - Non-Broadcast Multiple Access ip ospf network-type non-broadcast
Point-To-Point Broadcast ip ospf network-type point-to-point
Point-To-Point Non-broadcast ip ospf network-type point-to-point non-broadcast
Point-To-Multipoint Broadcast ip ospf network-type point-to-multipoint
Point-To-Multipoint Non-broadcast ip ospf network-type point-to-multipoint non-broadcast
A good rule to follow is that any OSPF network type that uses the term "Point" will not elect a DR/BDR, in these instances there really is no need for a Designated router. Considering a Designated Router does all the work for OSPF we also have to be aware of OSPF multicast addresses: 224.0.0.5 is for only DR/BDR routers, and 224.0.0.6 is for all SPF routers.
In a non-broadcast scenario each neighbor must be manually assigned within the OSPF router global configuration: neighbor 10.0.0.2 as an example.
configure Terminal
interface ethernet 0
ip address 10.2.2.0 255.255.255.0
ip ospf authentication-key some_key
ip ospf cost 10
interface ethernet 1
ip address 192.168.1.0 255.255.255.0
ip ospf authentication-key some_key -- specifies the key-string for the shared authentication key
ip ospf cost 20 -- manually set the cost of the interface rather than letting auto-cost do its work
ip ospf retransmit-interval 10 -- sets the retransmit of lost OSPF packets to 10
ip ospf transmit-delay 2 -- delay of time between transmits
ip ospf priority 4 -- 0-255; When two routers are attached to a network both will attempt to become the designated router but the router with the higher router priority takes precedence. If there is a tie, the router with the higher router ID takes precedence. A router with a router priority set to 0 cannot become the designated router or backup designated router.
Cisco NX-OS uses this priority value when you configure OSPF for broadcast networks using the neighbor command in router configuration mode.
interface ethernet 2
ip address 192.168.2.0 255.255.255.0
ip ospf authentication-key some_key
ip ospf cost 10
ip ospf router 201 area 192.168.2.0
interface ethernet 3
ip address 172.16.0.0 255.255.0.0
ip ospf authentication-key some-key
ip ospf cost 20
ip ospf dead-interval 80
router ospf 201
network 10.0.0.0 0.255.255.255 area 10.0.0.0
network 192.168.1.0 0.0.255.255 area 192.168.1.0
network 172.16.0.0 0.0.15.255 area 0
area 0 authentication
area 10.10.0.0 stub
area 10.10.0.0 authentication
area 10.10.0.0 default-cost 20
area 192.168.0.0 authentication
area 10.0.0.0 range 10.0.0.0 255.0.0.0
area 192.168.1.0 range 192.168.0.0 255.255.255.0
area 0 range 172.16.0.0 255.255.255.0
redistribute igrp 200 metric-type 2 metric 1 tag 200 subnets
redistribute rip metric-type 2 metric 1 tag 200
router igrp 200
network 172.16.0.0
router rip
network 192.168.2.0
redistribute igrp 200 metric 1
redistribute ospf 201 metric 1
Bidirectional Forwarding Detection is a detection protocol that provides a sub-second bidirectional path failure detection to Layer 3 protocols. BFD can be used by Layer 3 protocols: BGP, OSPF, EIGRP, IS-IS, HSRP, PIM, OTV, and static routing.
You can read more about BFD in the RFCs 5880, 5881, 7880, and 8562.
You can use BFD for fast failure detection instead of tuning the hello timers of other protocols that don't support subsecond failure detection. BFD provides subsecond failure detection between two connected devices. BFD can also be less intensive on CPU resources over hello messages because BFD can be distributed on the data plane by some Nexus 7000 supported I/O modules.
NX-OS supports BFD in asynchronous mode, which sends BFD control packets between two adjacent devices to activate and maintain BFD neighbor sessions. When you enable BFD on an interfaces and within the protocols configuration, such as OSPF, NX-OS creates a BFD session, negotiates BFD session parameters, and sends BFD control packets to each neighbor at the specified or negotiated interval.
The BFD session is included with the other protocol negotitation
- OSPF discovers a neighbor using Hello messages
- OSPF sends a request to the BFD process to start the BFD neighbor session
- The BFD neighbor session is established
- When Nexus switches establish a BFD session and complete their timer negotiations, BFD control packets are sent between the neighbors
- When BFD detects a failure, BFD will send a failure detection to OSPF, OSPF then initiates the protocol recalculation process to find an alternate path
BFD configuration:
no hardware ip verify fragment
no hardware ip verify address identical
feature bfd
interface vlan 1
no ip redirects
router ospf 1
bfd
Multi Protocol Border Gateway Protocol - MP-BGP takes many forms, in this section we will focus on BGP allowing IPv4 & IPv6.
BGP supports the following protocols -- address-family {ipv4 | ipv6} {unicast | multicast}
BGP is mostly used for external based routing, such as the internet, for its slow convergence times (it can take a while to start reconvergence rather than immediately like on IGP). BGP comes in two flavors: eBGP (external) & iBGP (internal) depending on how BGP connects to its neighbors: based on autonomous system numbers eBGP occurs when two neighbors are in different ASs, and iBGP occurs when two neighbors are in the same AS.
Currently BGP is in Version 4. Version 4 allows for multiprotocol extensions and allows for carrying traffic for multicast, IPv4 & IPv6, community & extended community attributes, & VPNv4
As for BGP configuration there are these initial three steps:
- Enable the BGP feature
- Start the BGP process with the AS number
- Configure peers
feature bgp
router bgp 65000 -- Starts the bgp process and places this configuration in autonomous system 65000
router-id 1.1.1.1 -- Sets the router-id for the local router
address-family ipv4 -- Sets the protocol to IPv4
template peer-policy TemplateName -- Configures a peer-template to be recalled by other neighbors
maximum-prefix 20 -- Sets a maximum prefix for this neighbor
neighbor 192.168.1.1 remote-as 65536 -- Specifies a neighbor and sets the neighbor's AS to 65536, eBGP
address-family ipv6 unicast -- Sets the neighbor protocol to IPv6
inherit peer-policy TemplateName -- Specifies the neighbor to use the configured template
neighbor 172.16.0.2 remote-as 65000 -- Specifies a neighbor and sets the neighbor's AS to 65000, iBGP
address-family ipv4 unicast -- Sets the neighbor protocol to IPv4
neighbor 192.168.0.2 remote-as 65001 -- Specifies a neighbor and sets the neighbor's AS to 65001, eBGP
update-source loopback0 -- By default the source interface is the outgoing interface, changes the source of the BGP session and updates
address-family ipv4 unicast -- Sets the protocol to IPv4
next-hop-self -- By default iBGP sets the next-hop to the originating router, this updates the next-hop to self
Protocol Independent Multicast
First Hop Redundancy Protocols