Computer Software

To pass the BSCI exam and earn your CCNP certification, you’ve got to master the (many) details of OSPF. You might have thought there were quite a few OSPF details in your CCNA studies, but you’ll now build on that foundation on the way to earning your CCNP.

One such detail is the role of the Autonomous System Border Router (ASBR) in OSPF. The name itself raises some eyebrows, since you learned in your CCNA studies that OSPF doesn’t use autonomous systems! Just as an OSPF Area Border Router borders multiple OSPF areas, the ASBR borders the entire OSPF domain and another source of routes. This can be another dynamic routing protocol, or directly connected networks that are not being advertised into OSPF by the network command.

Let’s say we have a router running both OSPF and RIP version 2. By default, the RIP process will not contain any OSPF-discovered routes, and vice versa. The two separate routing processes are just that – separate. If we want the other OSPF routers to know about the RIP routes, route redistribution must be configured. When the RIP routes are redistributed into OSPF, that router is then an ASBR.

In the below example, RIP subnets have been redistributed into OSPF. A seed metric is not necessary when redistributing routes into OSPF. The command “show ip ospf” confirms that this router is now an ASBR.

R1(config)#router ospf 1

R1(config-router)#redistribute rip subnets

R1#show ip ospf

Routing Process “ospf 1″ with ID 1.1.1.1

Supports only single TOS(TOS0) routes

Supports opaque LSA

It is an autonomous system boundary router

The ASBR can also perform route summarization on the routes being injected into OSPF with the summary-address command. (To configure OSPF inter-area summarization, use the area range command.) By mastering route summarization and route redistribution, you’re well on your way to passing the BSCI exam and earning your CCNP certification!

While studying to pass the BSCI exam and preparing to earn your CCNP certification, you’ll quickly notice that while OSPF and ISIS are both link-state protocols, there are a lot of differences between the two. One major difference is the way the two protocols handle hello packets.

Hello packets are imperative to keeping OSPF and ISIS adjacencies alive. Since they are both link-state protocols, neither of them will send updates at any specified time. Hello packets are the only method by which routers running OSPF and ISIS can see that a neighboring router is still available.

OSPF gives us some great options when it comes to keeping routing table size down via the use of stub and total stub areas, but to OSPF, a hello packet is a hello packet. ISIS routers are capable of sending two different types of hellos – Level 1 and Level 2.

ISIS routers are classified as Level 1 (L1), Level 2 (L2), and Level 1-2 (L1-L2). By default, Cisco routers are L1-L2 routers; this means that every ISIS-enabled interface will send out both L1 and L2 hellos.

If one of the interfaces is forming only an L1 or L2 adjacency, there’s no reason to send out hellos for the other adjacency type. For example, if R1 is forming an L1 adjacency with R2 via its ethernet0 interface, there is no reason to allow the router to transmit L2 hellos. To hardcode a router interface to send only L1 or L2 hellos, use the isis circuit-type command.

R1(config)#interface ethernet0

R1(config-if)#isis circuit-type level-1

Note: To configure this interface to send only L2 hellos, the full command is “isis circuit-type level-2-only”, not just “level-2″.

This configuration would prevent L2 hellos from being transmitted out ethernet0. While this does save router resources and prevents unnecessary bandwidth usage, there is also no way an L2 adjacency can be formed – so double-check your network topology before using this command!

When you’re studying for the BSCI exam on the way to earning your CCNP certification, you’ve got to master the use of BGP attributes. These attributes allow you to manipulate the path or paths that BGP will use to reach a given destination when multiple paths to that destination exist.

In this free BGP tutorial, we’re going to take a look at the NEXT_HOP attribute. You may be thinking “hey, how complicated can this attribute be?” It’s not very complicated at all, but this being Cisco, there’s got to be at least one unusual detail about it, right?

The NEXT_HOP attribute is simple enough – this attribute indicates the next-hop IP address that should be taken to reach a destination. In the following example, R1 is a hub router and R2 and R3 are spokes. All three routers are in BGP AS 100, with R1 having a peer relationship with both R2 and R3. There is no BGP peering between R2 and R3.

R3 is advertising the network 33.3.0.0 /24 via BGP, and the value of the next-hop attribute on R1 is the IP address on R3 that is used in the peer relationship, 172.12.123.3.

The issue with the next-hop attribute comes in when the route is advertised to BGP peers. If R3 were in a separate AS from R1 and R2, R1 would then advertise the route to R2 with the next-hop attribute set to 172.12.123.3. When a BGP speaker advertises a route to iBGP peers that was originally learned from an eBGP peer, the next-hop value is retained.

Here, all three routers are in AS 100. What will the next-hop attribute be set to when R1 advertises the route to its iBGP neighbor R2?