Route My World!

A CCNA/CCNP/CCIE Blog

Archive for the 'Routing Protocols' Category

BGP RIB Failure

Posted by Aragoen Celtdra on 1st August 2011

While going through some BGP examples in Routing TCP/IP Volume II, I came across an issue where RIB failures continue to pop up in the show commands. To illustrate see the following topology I recreated from the book (pg 175, fig 3-6 on Routing TCP/IP II book)

sh ip bgp produces the following output with the “r>” indicating that there is a RIB failure in router Vail.

sh ip bgp rib-failure provides a clue as to what caused the RIB failure

Further troubleshooting shows why

Telluride is advertising prefixes 192.168.1.200/30, 192.168.50.0, and 192.168.75.0 via IBGP towards Vail. Vail, however, is also learning these same routes via OSPF through Aspen. As shown in the sh ip route output for one of the routes above, an OSPF advertisement has an AD of 110, whereas an IBGP advertisement has an AD of 200. Even though the routes are in Vail’s BGP table, the OSPF route is installed in the routing table because of lower administrative distance. BGP then throws a fit because he has the routes in his table and the router ignored him. ;-)

This is normal operation for BGP. In fact, even though Vail does not use the route via BGP it is not suppressed or thrown out. If you check the ip routing table in Taos, you’ll see that BGP is sending these same routes from Vail. So at least BGP is happy there

Posted in BGP | 6 Comments » | Print This Post

CCIP???

Posted by Aragoen Celtdra on 25th May 2011

I’m starting to contemplate taking the CCIP track. I’ve been having a lot of fun with MPLS and BGP lately that I have  this compelling urge to go all the way with the IP track. The only thing that really holds me back is QoS. LOL! For some weird reason, QoS can’t seem to sit well with me. I don’t think it’s way more complicated than either MPLS or BGP, in terms of understanding the concepts. It’s just that it doesn’t seem to arouse interest in me. But then again, frame relay used to suck for me, but now we’re coo. ;-)

So CCIP or not? If I do, it would push back my goal of getting the CCIE R&S. On the upside, I’ll probably know BGP well enough to get it out of the way in my CCIE studies. MPLS doesn’t go much in depth in CCIE R&S but taking the CCIP MPLS exam should give me that much more command of the technology.

We shall see where it leads me. For now, to more MPLS fun…

Posted in BGP, CCIP, MPLS, QoS | 7 Comments » | Print This Post

BSCI Exam Resources

Posted by Aragoen Celtdra on 24th March 2009

While trying to organize the multitudes of Cisco documentation web links I’ve accumulated over the past year, I re-discovered these links that I dismissed as trifle information back when I first came across them. I guess I felt that way then because I didn’t consider the information lengthy enough to contain comprehensive theoretical background:

But while looking over some of the FAQs contained in them, I was surprised to discover how many of the very same questions appeared on the BSCI exam (albeit worded and used on the exam a little differently – but the same information nonetheless).

In my opinion, in order to get the most out of the FAQs, you’ll have to thoroughly understand the theories behind each technologies first – this is done by reading your theory books. Once you understand the general makeup and operation of the protocols, the FAQs can serve as review questions that  can be used to verify how much of the details you can remember. The way I would use them in the future is to categorize each protocols, copy the questions into a set of index cards/flash cards (or something similar) and drill myself until I’ve memorized the information.

Posted in BGP, BSCI Exam Prep, CCNP, EIGRP, Hot Links, Multicast, OSPF, Resources, Routing Protocols, Study Strategy | No Comments » | Print This Post

Examining the OSPF Neighbor Exchange Process

Posted by Aragoen Celtdra on 19th February 2009

Using the Hello protocol, there is a series of exchanges that routers go through in order to establish relationship when OSPF is initilized. I’d like to go through some of this steps using examples from a lab environment, and watching some debug output in the process.

To start, here’s the setup for the exercise:

Figure 1: A simple topology
ospfexchprotoc

Dynamips .net Config:

# OSPF Neighbor Exchange Lab Topology
autostart = False
ghostios = true
sparsemem = true
[localhost]

   [[7200]]
        image = \Program Files\Dynamips\images\C7200-JK.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 96
        ghostios = True
   
    [[ROUTER A]]
        Fa0/0 = B Fa0/0
        model = 7200
        console = 2001

    [[router B]]
        model = 7200
        console = 2002

Down State

Figure 2: Router A – interface added to OSPF
ospfdownstate2

  • When the router is enabled on the LAN, it starts in the Down state and starts sending out hello packets to multicast address 224.0.0.5.
  • When in Down state, it doesn’t mean that the interface or router itself is down. It’s just that it hasn’t received any Hellos from any neighbors.
  • When an interface is enabled on OSPF, it starts sending out Hello packets to multicast 224.0.0.5 as seen in the figure above.
  • Notice also that after sendnig Hello packets 4 times (40 seconds) and not finding an OSPF neighbor, it takes it upon itself to elect itself as a Designated Router (DR) for that LAN segment.

Init State

  • The init state indicates that a router sees HELLO packets from the neighbor, but two-way communication has not been established. A Cisco router includes the Router IDs of all neighbors in the init (or higher) state in the Neighbor field of its HELLO packets. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the Neighbor field of the neighbor’s HELLO packets.

Figure 3: Router B turns on OSPF on Fa0/0
b-up

Figure 4: Router A Goes to Init State
a-init

  • At 4:43:11 PM, Router B’s Fa0/0 is enabled for OSPF. Almost immediately it starts sending out Hello packets.
  • Within a few tenths of a second (at 4:43:17) Router A receives a packet from Router B with its database summary.
  • Router A also transitions to the Init state, indicating that although it has received something from Router B, nowhere in those packets is Router A’s Router-ID.
    • Remember, in order for the relationship two transition to the next level (two-way state), the receiver must receive a Hello from the other neighbor which contains its (Router A’s) own Router ID.
  • However, aside from needing to receive its own Router-ID in the neighbor field of the neighbors Hello packet, receiving a DBD from the neighbor also puts the state into a two-way state.
    • Looking at the output in figure 4, it confirms that Router A did receive a DBD from Router B.

Two-way State

  • In order to attain the 2-way state, a bi-directional communication has to be established between two routers.
    • That means that each router has seen the other’s hello packet.
  • When the router receiving the hello packet sees its own Router ID in the received Hello packet’s neighbor field.

Figure 5: Router A in Two-way State
a-2way

Figure 6: Router B in Two-way State
b-2way

  • I mentioned earlier that receiving a DBD from the neighbor puts the state in a 2Way.
  • In this particular example, Router B sent Router A a DBD as soon as it came up (see figure 4) and within milliseconds, Router A went from Init state to a 2way state.

DR Election

  • At the end of this state, DR and BDR elections also occur:

Figure 7: Router A – DR Election
a-drelection

Figure 8: Router B – DR Election
b-drelection

  • Recall that the router with the highest OSPF priority on a segment will become the DR for that segment.
    • In this case, the OSPF priority is not modified therefore they remain tied at default value of 1.
  • In case of a tie, the following Router-ID criteria is followed in order of highest priority (#1 being the best):
    1. Statically configured Router-ID using router-id command.
    2. Highest loopback interface.
    3. Highest active interface.
  • In the figures above, none of the provisions just mentioned are actually used. In fact, notice that Router A is the DR despite having a lower IP address.
    • To determine why, look back at when the neighbor exchange started. On the very first figure (figure 2) Router A has established itself as the DR when there were no neighbors up at the time. A DR will not give up its status even if a new interface with a higher priority in its Hello packet comes up. So even though Router B with better priority comes up, it will not preempt the already established DR.
    • You can change this by reloading the router or if the OSPF routing process restarts.

Exstart State

  • If the routers involved in the neighbor process are connected on a point-to-point link, the routers become Full after exchanging Hellos.
  • On Ethernet links, after the DR and BDR election has been established, a master-slave relationship is formed.
    • The router with the higher router-id becomes the master and initiates the exchange.

Figure 9: Router B – Exstart
b-exstart

Figure 10: Router A – Slave
a-slave

  • Notice that even though Router A is the DR, it doesn’t necesarrily become the master. Remember that the DR/BDR election can take place using a higher priority configured on the router. Or in this case, because Router A was elected a DR first, despite having a lower router ID.
  • Router B becomes master because it has a higher router-id regardless of who the DR is.

Exchange State

Figure 11: Router A  – Exchange
a-exchange1

Figure 12: Router B – Exchange
b-exchange1

  • Notice in the figures above that  OSPF routers exchange database descriptor (DBD) packets as they tranisition to the Exchange state.
    • DBDs contain link-state advertisement (LSA) headers that describe the contents of the LSDB.
  • Each DBD packet has a sequence number which can be incremented only by master. These
  • Notice also that the routers send link-state request (LS REQ) packets. Once received the router sends link-state update packets (which contain the entire LSA) to fulfill the requested information.
  • The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.

Loading State

  • This is when the actual exchange of link state information happens.
  • Link State requests are sent based on information provided by the DBDs -  information such as outdated or missing LSAs. The neighbor then sends the requested information back contained in Link State updates (LSUs).
    • All LSUs need to be acknowledged.

Figure 13: Router A: Loading-Full State
a-loading-full

Figure 14: Router B: Loading-Full State
b-loading-full

Full State

  • Routers achieve Full neighbor adjacency at this state. Network and router LSAs are exchanged and router databases are fully synchronized.

Posted in BSCI Exam Prep, CCNP, Dynamips, OSPF, Routing Protocols | 8 Comments » | Print This Post

Lab Notes: EIGRP ip default-network Command [Dynamips Lab]

Posted by Aragoen Celtdra on 15th February 2009

  • To configure the EIGRP default route, use the following global configuration command:

ip default-network network-number

  • The network-number will be announced to other routers as the last-resort gateway.
  • In order for the router – where this command is configured – can consider the network as a candidate default route, the network must be reachable by this router.
  • In addition, the network number in the command must also be passed to other EIGRP routers so that those routers can use this network as their default network and set their gateway of last resort to this default network. This could be:
    • An EIGRP-derived network in the routing table.
    • Generated with a static route and redistributed into EIGRP.

The following scenario is based on the example given in page 96 of the BSCI study guide.

eigrp-ip-default-network

Dynampis .net Config file:

# EIGRP ip-default network Command - page 96 Of BSCI study guide
autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        fa0/0 = B fa0/0
        s1/0 = C s1/0
        model = 7200
        console = 2001
        idlepc = #this is a system-specific setting

    [[router B]]
        model = 7200
        console = 2002
        idlepc = #this is a system-specific setting    

    [[router C]]
        model = 7200
        console = 2003
        idlepc = #this a system-specific setting

Router A Configuration:

!
interface FastEthernet0/0
 ip address 10.5.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 172.31.5.1 255.255.255.252
 serial restart-delay 0
!
!
router eigrp 1
 network 10.0.0.0
 network 172.31.0.0
 auto-summary
!
ip classless
ip default-network 172.31.0.0
!
  • The command ip default-network 172.31.0.0 is configured on Router A to allow 172.31.0.0 network as a candidate default network.
  • The command network 172.31.0.0 passes the network 172.31.0.0 to Router B, so that router B can use it as its default network and set its gateway of last resort to this network.

Router B configuration:

interface FastEthernet0/0
 ip address 10.5.1.3 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 1
 network 10.5.1.3 0.0.0.0
 auto-summary
!
ip classless
!

Router C configuration:

!
interface Serial1/0
 ip address 172.31.5.2 255.255.255.252
 serial restart-delay 0
!
router eigrp 1
  network 172.31.0.0
 auto-summary
!
ip classless

Router B: IP routing table:

B# sh ip route

Gateway of last resort is 10.5.1.1 to network 172.31.0.0

D*   172.31.0.0/16 [90/2172416] via 10.5.1.1, 00:10:38, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.5.1.0 is directly connected, FastEthernet0/0
  • The EIGRP-learned 172.31.0.0 network is marked as a candiate default network indicated by the * in the routing table.
  • The gateway of last resort is also set to 10.5.1.1 (Router A) to reach the default network 172.31.0.0.

Router A: IP routing table

A(config)#do sh ip route

Gateway of last resort is 0.0.0.0 to network 172.31.0.0

 *   172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
D*      172.31.0.0/16 is a summary, 00:12:27, Null0
C       172.31.5.0/30 is directly connected, Serial1/0
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:12:27, Null0
C       10.5.1.0/24 is directly connected, FastEthernet0/0
  • In earlier versions of IOS, the router on which the ip default-network command was configured would not set the gateway of last resort.
  • As highlighted above, it now sets the gateway of last resort to 0.0.0.0, to the network specified – 172.31.0.0.

Posted in BSCI Exam Prep, CCNP, Dynamips, EIGRP, Lab, Routing Protocols | 2 Comments » | Print This Post

Lab Notes: RIPv2 Automatic Network-Boundary Summarization [Dynamips Lab]

Posted by Aragoen Celtdra on 13th February 2009

  • By default, RIPv2 and EIGRP perform automatic network summarization at classful boundaries, just like a classful protocol does.
    • The diffrence between these two protocols and their predecessors (RIPv1 and IGRP) is that you can turn off automatic summarization.
    • To turn off, use the router configuration command:

no auto-summary

  • OSPF and IS-IS RIP and EIGRP perform automatic network summarization by default.

Example:

ripv2-autosumm

  • The diagram above shows a RIPv2 network where autosummarization occurs.

Dynamips .net Configuration:

autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = \Program Files\Dynamips\images\c7200-js-mz.124-3\C7200-JS.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        S1/0 = B s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router B]]
        s1/1 = C s1/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router C]]
        model = 7200
        console = 2003
        idlepc = 0x607016a0

Router A Config:

!
interface FastEthernet0/0
 ip address 172.16.2.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 172.16.1.1 255.255.255.0
 serial restart-delay 0
!
router rip
 version 2
 network 172.16.0.0

Router B Config:

!
interface Serial1/0
 ip address 172.16.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial1/1
 ip address 192.168.5.2 255.255.255.0
 serial restart-delay 0
!
router rip
 version 2
 network 172.16.0.0
 network 192.168.5.0
!

Router C Config:

!
interface Serial1/0
ip address 192.168.5.1 255.255.255.0
serial restart-delay 0
!
router rip
version 2
network 192.168.5.0
!
  • In the RIPv2 network above, Router B performs a defualt behavior of automatically summarizing the 172.16.1.0/24 and 172.16.2.0/24 networks learned from B’s connected subnet and A’s advertised subnet.
C# sh ip route
Gateway of last resort is not set

R    172.16.0.0/16 [120/1] via 192.168.5.2, 00:00:05, Serial1/0
C    192.168.5.0/24 is directly connected, Serial1/0
  • In Router C’s routing table, notice that it, indeed, learns of a summarized route from it’s neighbor 192.168.5.2, which is Router B.
  • A simple no auto-summary command on Router B, changes the routing table on Router C.
B(config)#router rip
B(config-router)#no auto-summary
  • Now looking at Router C’s IP routing table, we see:
C# sh ip route
Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R       172.16.0.0/16 [120/1] via 192.168.5.2, 00:00:29, Serial1/0
R       172.16.1.0/24 [120/1] via 192.168.5.2, 00:00:00, Serial1/0
R       172.16.2.0/24 [120/2] via 192.168.5.2, 00:00:00, Serial1/0
C    192.168.5.0/24 is directly connected, Serial1/0
  • Notice now that both 172.16.1.0/24 and 172.16.2.0/24 networks are advertised with both prefix and subnet mask.

Posted in BSCI Exam Prep, CCNP, Dynamips, Lab, Routing Protocols | 2 Comments » | Print This Post

Lab Notes: RIP, Classful Summarization, Auto-summarization [Dynamips Lab]

Posted by Aragoen Celtdra on 12th February 2009

Classful Routing Protocol Concepts

  • Classful routing protocols do not include subnet mask information in their routing updates.
  • A router sends the entire subnet address when an update packet involves a subnet of the same classful network as the IP address of the transmitting interface.
  • If sending an update about a subnet of a network across an interface belonging to a different network, the router will send the classful summary route. This is called autosummarization across the network boundary.

Example:

classfulnetsumm1

Dynagen configuration:

autostart = False
ghostios = true
sparsemem = true

[localhost]

[[7200]]
image = C7200.BIN
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
npe = npe-400
ram = 160

[[ROUTER A]]
S1/0 = B s1/0
model = 7200
console = 2001
idlepc = 0x6082d7a0

[[router B]]
s1/1 = C s1/0
model = 7200
console = 2002
idlepc = 0x607016a0

[[router C]]
model = 7200
console = 2003
idlepc = 0x607016a0

Router A Config:

interface FastEthernet0/0
 ip address 10.1.0.1 255.255.0.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 10.2.0.1 255.255.0.0
 serial restart-delay 0
!
router rip
 network 10.0.0.0
!
ip classless

Router B Config:

interface FastEthernet0/0
 no ip address
 shutdown
 duplex half
!
interface Serial1/0
 ip address 10.2.0.2 255.255.0.0
 serial restart-delay 0
!
interface Serial1/1
 ip address 172.16.2.2 255.255.255.0
 serial restart-delay 0
!
router rip
 network 10.0.0.0
 network 172.16.0.0
!
ip classless

Router C Config:

interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 172.16.2.1 255.255.255.0
 serial restart-delay 0
!
router rip
 network 172.16.0.0
!
ip classless
Router B: show ip route
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial1/1
C       172.16.2.0 is directly connected, Serial1/1
     10.0.0.0/16 is subnetted, 2 subnets
C       10.2.0.0 is directly connected, Serial1/0
R       10.1.0.0 [120/1] via 10.2.0.1, 00:00:21, Serial1/0
  • In the output above, Router A advertises the 10.1.0.0 subnet to router B because the interface connecting them belongs to the same major classful 10.0.0.0 network. When router B receives the update packet, it assumes that the 10.1.0.0 subnet uses the same 16-bit mask as the one used on its 10.2.0.0 subnet.
  • Similarly, Router C advertises the 172.16.1.0 subnet to router B because the interface connecting them belongs to the same major classful 172.16.0.0 network. Therefore, router B’s routing table has information about all the subnets that are in use in the network.
Router A: show ip route
Gateway of last resort is not set

R    172.16.0.0/16 [120/1] via 10.2.0.2, 00:00:16, Serial1/0
     10.0.0.0/16 is subnetted, 2 subnets
C       10.2.0.0 is directly connected, Serial1/0
C       10.1.0.0 is directly connected, FastEthernet0/0
  • In the output above however, router B summarizes the 172.16.1.0 and 172.16.2.0 subnets to 172.16.0.0 before sending them to router A. Therefore, router A’s routing table contains summary information about only the 172.16.0.0 network.

classfulnetwsumm

Router C: show ip route
Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
C       172.16.2.0 is directly connected, Serial1/0
R    10.0.0.0/8 [120/1] via 172.16.2.2, 00:00:02, Serial1/0 
  • Similarly above, router B summarizes the 10.1.0.0 and 10.2.0.0 subnets to 10.0.0.0 before sending the routing information to router C. This summarization occurs because the update crosses a major network boundary. The update goes from a subnet of network 10.0.0.0, subnet 10.2.0.0, to a subnet of another major network, network 172.16.0.0. Router C’s routing table contains summary information about only the 10.0.0.0 network.


Posted in BSCI Exam Prep, CCNP, Dynamips, Routing Protocols | 2 Comments » | Print This Post

Lab Notes: On-Demand Routing (ODR) [Dynamips lab]

Posted by Aragoen Celtdra on 11th February 2009

On Demand Routing (ODR)

  • Applicable in a hub-and-spoke topology only.
  • Uses Cisco Discovery Protocol (CDP)
    • Sent as multicast
    • Sent every 60 seconds by default
      • cdp timer adjusts the timer.
    • Enabled by default.
    • Except ATM where CDP must be explicitly enabled.
  • Configured on hub router
    • router odr global configuration command.
  • Stub router can’t have an IP routing protocol. In fact, no IP routing protocol is considered a stub by ODR.
  • WAN links such as dialer links and Frame Relay, use broadcast keyword in mapping statements.

Example:

odr

autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        S1/0 = B s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router B]]
        s1/1 = C s1/0
        s1/2 = D s1/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router C]]
        model = 7200
        console = 2003
        idlepc = 0x607016a0

    [[router D]]
        model = 7200
        console = 2004
        idlepc = 0x607016a0

Here’s the configs:

Router B (Hub Router):

interface Loopback0
 ip address 10.4.1.1 255.255.255.255
!
interface Serial1/0
 ip address 10.1.1.1 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 ip address 10.2.2.1 255.255.255.252
 serial restart-delay 0
!
interface Serial1/2
 ip address 10.3.3.1 255.255.255.252
 serial restart-delay 0

Router A:

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface Serial1/0
 ip address 10.1.1.2 255.255.255.252
 serial restart-delay 0

Router C:

interface Loopback0
 ip address 172.16.2.1 255.255.255.0
!
interface Serial1/0
 ip address 10.2.2.2 255.255.255.252
 serial restart-delay 0
!

Router D:

interface Loopback0
 ip address 172.16.3.1 255.255.255.0
!
interface Serial1/0
 ip address 10.3.3.2 255.255.255.252
 serial restart-delay 0
!
  • As soon as ODR is configured and running, routes from the stub routers are identified in the hub router’s routing table with an o character (shown below)
  • Notice in the example that the metric is 1, and the administrative distance for ODR is 160.
  • Also, do not confuse the o character of ODR routes with the O character of OSPF routes.
B#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 3 subnets
o       172.16.1.0 [160/1] via 10.1.1.2, 00:00:56, Serial1/0
o       172.16.2.0 [160/1] via 10.2.2.2, 00:00:54, Serial1/1
o       172.16.3.0 [160/1] via 10.3.3.2, 00:00:55, Serial1/2
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.3.3.0/30 is directly connected, Serial1/2
C       10.2.2.0/30 is directly connected, Serial1/1
C       10.1.1.0/30 is directly connected, Serial1/0
C       10.4.1.1/32 is directly connected, Loopback0

Posted in BSCI Exam Prep, Dynamips, Routing Protocols | No Comments » | Print This Post

BSCI: BGP Attributes III

Posted by Aragoen Celtdra on 19th December 2008

Local Preference Attribute

  • Local preference is a well-known discretionary attribute that tells the routers in an AS which path is the preferred path to exit the AS.
  • If an internal BGP speaker receives a multiple routes to a destination, the router compares the LOCAL_PREF attribute of the routes.
    • The path with the higher local preference is chosen.
  • Local preference is exchanged only among routers in the same AS, among internal BGP neighbors; it is not passed to other autonomous system (ie other EBGP peers).

  • In the figure above, AS100 receives advertisement for network 172.16.1.0/24 from two different points.
  • As Router A receives the advertisement from Router C, Router A sets the LOCAL_PREF to 50.
  • Likewise, when Router B receives the advertisement to the same network (172.16.1.0/24), Router B sets the LOCAL_PREF to 100.
  • These local preference values will be exchanged between IBGP neighbors, Routers A and B.
  • Based on the higher value LOCAL_PREF for Router B, Router B will be use as the exit point for AS 100 to reach network 172.16.1.0 in AS 200.

Multi-exit Discriminator (MED) Attribute

  • Whereas the local preference attribute affects traffic leaving the AS, The MED attribute influences incoming traffic.
  • Also called the metric. A lower metric is preferred. As is true with most “metrics”, the lowest metrics means the shortest distance, and thus the preferred one.
    • MED is set to 0 (zero) by default.
  • This attribute is carried in EBGP updates and allows an AS to indicate to another AS its preferred incoming points.
  • By default, a router compares the MED attribute only for paths from the neighbors in the same AS.
  • The MED is exchanged between two directly connected autonomous systems only.
    • MEDs are not passed beyond the receiving AS.

  • In the Figure above,  a subscriber in AS 200 is dual-homed to a single ISP (AS 100).
  • Within AS 100, IBGP is being used between the routers. The MEDs from AS 200 are exchanged between these internal peers so that they both know which route to prefer.
  • MEDs also do not go past beyond the receiving AS. IF AS 100 advertises 172.16.1.0/24 to another AS, for instance, it does not pass along the MED set by the originating AS; AS 200 in this case.
  • Additionally, MEDs are not compared if two routes to the same destination are received from two different autonomous systems.
    • For example, 172.16.1.0/24 is advertised from AS 200 and another AS, the MEDs are not compared.
    • MEDs are meant only for a single AS (with multiple entry point) in order to compare which entry point to prefer.

Community Attribute

  • Communities are optional transitive attributes that is designed to simplify policy enforcement. It is one way to filter incoming or outgoing routes.
  • BGP communities allow routers to tag routes with a community indicator and allow other routers to make decisions based on that tag.
    • It Identifies a route as a member of some community of routes that share some common properties.
    • An example might be an ISP that assigns a particular COMMUNITY attribute to all of its customers’ routes. The ISP may then set its LOCAL_PREF attribute based on the COMMUNITY value instead of basing it on each inidividual route.
  • The community attribute was originally a Cisco-speficific attribute. But now a RFC standard through RFC 1997.

Weight Attribute (Cisco Only)

  • The weight attribute is a Cisco-specific attribute.
  • It is configured locally on the router and is not communicated or propagated to other routers.
  • The weight ha a value between 0 to 65,535.
    • By default, all routes generated by the local router have a weight of 32,768.
    • All routes learned from a peer have a weight of 0.
    • The higher the weight, the more preferable the route.
  • The weight attribute applies when using one router with multiple exit points out of an AS.
    • Contrast it with the local preference attribute where it is used when two or more routers provide multiple exit points.

  • In the figure above, Router A receives an advertisement for network 172.16.1.0/24 from Routers B and C.
    • Router A knows about more than one route to the same destination.
  • The route coming from Router B has an associated weight of 50.
  • The route coming from Router C has an associated weight of 100.
  • Both paths for network 172.16.1.0 will be in the BGP routing table, with their respective weights.
  • The route with a higher weight will be installed in the IP routing table.

Resources:

  1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
  2. RFC 4451 – BGP MULTI_EXIT_DISC (MED) Considerations
  3. RFC 1997 – BGP Communities Attribute
  4. RFC 1998 -An Application of the BGP Community Attribute in Multi-home Routing

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | No Comments » | Print This Post

BSCI: BGP Attributes II

Posted by Aragoen Celtdra on 18th December 2008

AS-Path Attribute

  • Whenever a route update passes through an AS, the AS number is prepended to that update when it is advertised to the next EBGP neighbor.
  • The AS-path attribute is the list of AS numbers that a route has traversed to reach a destination, with the number of the AS that originate the route at the end of the list.
  • The AS-Path attribute avoids routing loops by the local AS simply rejecting any route object that contains its own AS in the AS_PATH attribute.
  • The BGP system prefers the route object with the shortest AS_PATH attribute length.

  • In the above figure, AS1 originates a network 10.0.0.0/8 and advertises it to AS2 and AS3. AS1 adds its own AS number to the AS_PATH.
  • AS2 and AS3 learns of the route with an associated path vector of <AS1>.
    • AS2 advertises the route to its neighbor AS 4. AS2 prepends its own AS number to the AS_PATH.
    • AS3 advertises the route it learns from AS1 to AS5. AS3 prepends its own AS to the AS_PATH.
  • AS4 learns of the route from AS2 with an associated path vector of <AS2, AS1>.
  • AS 5 eventually learns two paths to 10.0.0.0/8.
    • One with a path vector of <AS3, AS1>
    • Another with path vector of <AS4, AS2, AS1>
  • AS5 will select the shortest path to reach 10.0.0.0/8. This path is the one that goes though AS3 –> AS1.
    • This path that AS5 chose will also be advertised to its adjacent AS peers.
  • Loop prevention mechanism on BGP will not allow AS5 to advertise the same path to AS1 because AS1 is already in the path vector.

Next-Hop Attribute

  • The next-hop attribute indicates the next-hop IP address to reach a destination.
  • The next-hop IP address is not always the address of a neighboring router.
    • For EBGP, the next-hop is the IP address of the neighbor that sent the update.
    • For IBGP, it stipulates that the next hop advertised by EBGP should be carried into IBGP.
      • It is not necessarily the connected IGP neighbor that is advertised as the BGP next hop address.

Example 1

  • Consider the diagram above, Router B learns the network 172.16.0.0 from Router A, with the next-hop IP address of 10.10.10.3. Likewise, A uses 10.10.10.1 as the next hop IP address to get to 172.20.0.0.
  • Because the rule for IBGP states that the next hop advertised by EBGP should be carried into IBGP, Router B advertises to its IBGP peer Router C the network 172.16.0.0, with the next hop of 10.10.10.3 (not 172.20.10.1 as we’re accustomed to seeing in the IGP world).
  • It is important that Router C knows how to reach the 10.10.10.0 subnet, otherwise packets destined for 172.16.0.0 could be dropped.
    • Router C can learn about network 10.10.10.0 by IGP or static route.
  • An IGP uses the IP address of a routing update (route source) as the next-hop address.
  • BGP uses a separate field for each network to record the next-hop address.
  • IBGP neighbors use recursive lookup to reach BGP next-hop address by using its IGP entries in the routing table.
    • Router C learns about 172.16.0.0 from Router B (route source 172.20.10.1) with Router A (10.10.10.3) as the next hop.
    • Router C, therefore, installs the route to 172.16.0.0/16 in the routing table with a next hop of 10.10.10.3
    • With Router B using an IGP to announce network 10.10.10.0/24 to Router C, Router C also installs 10.10.10.0/24 in its routing table with a next hop of 172.20.10.1.
    • When Router C sends a packet to a destination in the 172.16.0.0. network, it looks up the network in the routing table and finds a BGP route with a next hop of 10.10.10.3.
    • Because it is a BGP entry, Router C completes a recursive lookup in the routing table for a path to network 10.10.10.3.
      • There is an IGP route to network 10.10.10.0 in the routing table with a nesxt hop of 172.20.10.1.
    • Router C then forwards the packet destined for the network 172.16.0.0 to 172.20.10.1.

Example 2: Next-Hop Attribute on Multiaccess Network

  • In the above diagram, Routers B and C in AS 65000 are running an IGP.
    • Router B can reach network 172.30.0.0 via 10.10.10.2.
    • Router C can reach network 172.20.0.0 via 10.10.10.1.
  • B and C are also running IBGP between each other.
    • Router B is running EBGP with Router A.
    • Router C is running EBGP with Router D.
  • When B sends a BGP update to A about 172.30.0.0, it gives 10.10.10.2 (Router C) as the next hop, and not it’s own address.
    • This feature is called a third-party next hop.
      • A BGP speaker can advertise to an external peer an interface of any internal peer router in the next hop component, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. – RFC 2858.
      • It basically means that in a multi-access network, a BGP router can use the a next hop address that is not necessarily its own, by changing the next-hop attribute, in order to avoid inserting additional hops into the path.
  • In the scenario above, If Router A needs to send update to AS 64600, Router B tells Router A to install the AS 64600 networks with next hop address of 10.10.10.2 (Router C)
    • To get to AS 64600, Router A must go through AS 65000.
    • Router B advertises AS 64600 networks to Router A because they have neighbor relationship. But because Router B does not handle traffic to AS 64600, and Router C has neighbor relationship with Router D in AS 64600, Router B tells Router A to get to AS 64600 through Router C. This is of course dependent on Router A and C being on the same subnet.

Example 3: Next-hop Attribute on NBMA

  • In the above figure, Routers A, B, and C are connected via Frame Relay.
  • Router B has a Frame Relay map entry for Router C, therefore it can reach network 172.30.0.0, using 10.10.10.2 as the next hop address.
  • Router B, with a an EBGP neighbor relationship with Router A, sends a BGP update to Router A about 172.30.0.0, using 10.10.10.2 as the next hop address.
  • A potential problem can occur if there is no way for Routers A and C to communicate directly because of missing Frame Relay map entry to each other.
    • One solution, of course, is to add a Frame Relay map entry between the two.
    • Another option is a configuration feature called next-hop-self.
      • This configuration is set on Router B by configuring itself to advertise its IP address as the next-hop attribute.

As mentioned earlier, the IP address of the next-hop is not always the address of the directly attached neighboring router. There are some rules that apply to determining the next-hop address:

  1. If the advertising router and receiving router are external peers (ie they are in different autonomous systems), the IP address of the advertising router’s interface is the next-hop address.
  2. If the advertising router and receiving routers are internal peers (in the same AS), and the destination is withing the same AS, the next-hop is the address of the router that advertised the route.
  3. If the advertising router and the receiving router are internal peers and the destination of the update is in a different AS, the next-hop is the IP address of the external peer from which the route was learned.

Origin Attribute

  • A well-known mandatory attribute that specifies the origin of routing updates.
  • It can be one of three values:
    1. IGP
      • The NLRI was learned from a protocol internal to the originating AS. BGP routes are given an origin of IGP when a network command is used to advertise the route via IGP.
      • An origin of IGP is given the highest preference of the ORIGIN values.
      • An origin of IGP is indicated with an i in the BGP table.
    2. EGP
      • This means that the route is learned from Exterior Gateway Protocol (EGP). This is not supported on the Internet because it only does classful routing and does not support CIDR.
      • This is the next preferred to IGP.
      • Indicated by an e in the BGP table
    3. Incomplete
      • This mens that the origin of the route is unknown or learned by other means.
      • Usually a result of a route being redistributed into BGP, because there is no way to determine the original source of the the route.
      • Lowest preferred ORIGIN value.
      • Indicated by a ? in the BGP table.

Resources:

  1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
  2. An Introduction to BGP – the Protocol – The ISP Column – Geoff Huston
  3. BGP AS-Path – Cisco IOS Hints and Tricks
  4. RFC 2858 – Multiprotocol Extensions for BGP-4

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | 1 Comment » | Print This Post