Route My World!

A CCNA/CCNP Blog

Archive for August, 2008

Fan Mail ;)

Posted by Aragoen Celtdra on 25th August 2008

I was just responding to a latest comment regarding some VPN-related stuff that I was doing and my response got too long that I thought I might as well turn it into a update post. The comment was:

Steve Says:
Have you labbed DMVPN yet? I wonder what would the requirements be to choose DMVPN design over ipsec\gre tunnels in an HA state. I am faced with a work related scenario (up to 100 remote sites and two data centers) and ponder which would be best solution and keeping it simple at the same time.

As far as labbing up DMVPN, I have not had the chance to do so. I have read a lot about it, though ;) We have four sites (stark contrast to your 100 remote sites) that are currently configured for DMVPN right now. Three other sites are using IPsec/GRE tunneling.

I wish I could speak a lot more intelligibly about the subject, but I am still learning. The past 3 weeks have been so much more educational for me as I’ve gotten so much more exposure to the network here at my workplace. I’ve been given complete access to all our routers to do all show commands I wish - almost a voyeuristic peek at someone’s network configuration and setup. As such I was able to relate everything I’ve learned so far by seeing how things are put together under the hood (i.e. routing tables, config syntax, etc.) It is pretty exciting to finally be given that opportunity.

Last week, my boss gave me a project to try to figure out how to set up a Client VPN on a Cisco Pix. I’m excited to report that I have been successful with configuring the ISAKMP/Ipsec settings so that I am now able to create a tunnel between a host computer from anywhere on the internet to our pix located in out main office. I was also successfully able to configure split-tunneling where I can now connect to the VPN and get internet access at the same time (whereas before, internet was inaccessible when I connect through the VPN.) Now if I can only figure out what is wrong with the routing so that I can access the internal LAN then that would be awesome ;)

Learning how to configure all these stuff on my own takes a lot of perseverance and dedication - just like studying for a cert. Often times, I find myself still reading documentations and trying out different configs until 2 in the morning. I did find, however, that the kind of perseverance required to get these things done is fueled by ones desire to really learn this stuff. As a result, i didn’t have to force myself to be up so late in the evening, configuring a device. I genuinely enjoy it, and as such, it doesn’t feel like a burden. Sometimes you just want to see things work that you don’t even notice how long you’ve been at it. And I think, that’s what I love about this profession. There is a certain element about it that you know, when you get it going, gives you a certain pleasure of knowing that you built that, or you configured that. Whatever it is that makes things work and make them communicate underneath has your footprints embedded in them.

I’m really excited for more. After this Client VPN project is done. My boss wants me to configure all the routers in our remote offices to connect to our pix and setup a site-to-site VPN. I will not be using DMVPN solution and I will not be using a Cisco (router) IOS-based solution that I’ve read all about in the past weeks. But whatever solution I use, it is going to be a worthwhile experience because this will only help me towards becoming a real network engineer that I’ve been wanting to be.

Posted in PIX/ASA, Security, VPN, Work | 9 Comments » | Print This Post

Back In the Swing

Posted by Aragoen Celtdra on 19th August 2008

Hopefully! I feel like I haven’t touched my studies in such a long time. In fact, it’s only been a week that I haven’t been studying on my normal pace.

Well, our vacation was pretty nice and relaxing. It’s funny how the days just seem to pass on by so quickly when you’re having fun. I was telling a coworker yesterday that it felt like I was never gone. We did a lot of resting and lazying around while on our brief sojourn. We ate a lot and watched a lot of the Olympic games. It was also my first time to Legoland. The team park was better than I expected and my 2-year old thoroughly enjoyed it. But like all good things… they will come again. But for now, it’s back to the grind again.

For the past week I’ve been thrown off course trying to learn everything I can about DMVPNs, IPSECs, GREs, etc. I’ve gone over an excellent DMVPN article by Petr Lapukhov of InternetworkExpert as well as Jeremy Stretch of PacketLife.net’s clear explanations. But most helpful for me was going through Cisco.com’s wealth of information on the subject. Here’s one as an example.

This week, however, I’d like to get back to my regularly scheduled programming and continue on with BSCI. I’d really like to finish of OSPF this week so I can move on to IS-IS next week. So for the rest of this week, these are my goals:

Tuesday: OSPF Route Summarization & OSPF Area Types (Pages 240-250 of the Self-study guide)

Wednesday: Configuring and Verifying OSPF Area Types (Pages 250-260 of the Self-study guide)

Thursday: OSPF Virtual Links (Pages 261-266)

Friday: OSPF Authentication (Pages 266-279)

Sat & Sun: Try to get through the Lab portion (This will be yet another busy weekend, so I’ll try to get as much done as I can.)

Posted in Aragoen's Musing, BSCI Exam Prep, CCNP, VPN | 3 Comments » | Print This Post

Been a while…

Posted by Aragoen Celtdra on 13th August 2008

Well OK. I haven’t been updating. That’s because, I have had so many distractions this week and I haven’t read any new materials since last friday. And it looks like the streak is going to continue - I, with my family, will be going to yet another vacation in San Diego. Now I know, we just went to San Diego a month ago for a vacation, but I wouldn’t really consider it the same thing. First off, the last time we went was on a weekend, so it wasn’t really a real vacation like you would take by taking days off from work. This time around, I’m taking two vacation days from work, which will roll into the weekend as well. Secondly, we’re going to a different part of San Diego. So consider this a continuation of my vacation from last time. ;)

So it doesn’t look like I’m going to be getting a lot of reading and notes done.

Here’s another reason for not having kept up with my readings: Playstation 3. Yup, I’ve got one. A real Playstation 3 right in my home. For the past year and a half, I’ve been begging my wife to let me buy an Xbox 360. She wouldn’t let me me. She thinks I’ll never do anything productive at home if I bought one. Sheeessh! What does she know? Turns out… a lot. Because for the past 5 days, all my precious free time has been spent shooting up terrorists on Call of Duty 4 and Battlefield: Bad Company. What awesome games! And what wastes of time!

Now I didn’t actually buy the console. My best friend from college came over last weekend with his family and brought his system to my house so we can play some. But he decided to leave it with me for an “indefinite” period because it is taking too much of his time when he gets home from work. He is an ER doc so he already works a lot of hours and he needed to give himself a break. In essence, he is leaving with me the device known to corrupt the minds of todays youth.

Did you want another reason excuse for me slacking off? The olympics man! Even when I tivo it, I still watch it during prime time. Why not? It only comes once every four years and you would be remiss if you fail to take part in these historic events being stamped in the pages of olympic lore. Ok, perhaps badminton doesn’t count but it’s still cool to watch. By the way, did anybody see that weightlifter whose elbows bent in a way it wasn’t meant to bend? That was a pretty gnarly sight!

Despite all these, the week wasn’t a complete waste. I have been reading a lot of Cisco docs on IPsec VPN and DMVPN. I’ve also read a few posts from bloggers about the same topics. Right now I’m working out a lab scenario to replicate our company’s site-to-site VPN setup. It is pretty fun and hopefully I can post some of it up in the future. It’s amazing how easy things become when you study them. Before I started Cisco, I only knew a few show and configuration commands such as assigning an IP to an interface. Now I can actually look at all of our routers’ configs and be able to identify what most of the commands do. It is most exhilarating feeling. Ok, it’s not. But it’s still very cool.

I’m still going to continue with the BSCI write-ups and hope to finish up OSPF this week. I’m kinda tempted to go past IS-IS and jump to BGP because BGP just sounds cooler for some reason. But most likely, I’ll stay with the format of the book so I don’t get all mixed up and confused as I already am.

Anyway, my weekend starts in a few hours so I better get the most out of it and come back re-charged for the next 6 months or so ;)

Posted in General | 4 Comments » | Print This Post

Dynamips Lab: OSPF Point-to-Multipoint Configuration

Posted by Aragoen Celtdra on 8th August 2008

So I was thinking, since I’ve been doing a lot of dynamips/dynagen labs for practicing routing, I thought I should start posting them as well so my blog friends can try them out and/or point out mistakes I might have made. I thought it might be a good way to collaborate with others and also maybe to help out others who don’t have home lab setups.

Since there are many websites out there doing tutorials, video instructions (read blindhog ;) ), and other general information that pertain to Dynamips/Dynagen, I thought I would just focus on specific exercises that cover what I’m currently studying. It makes sense anyway in that this whole website is dedicated to specific things that pertain to my study. And a lot of my regular readers are also folks who are in the same boat as I am.

Most of my examples will be based mostly on examples from Cisco Press’ BSCI Authorized Study Guide. A few of them like the one you see below will be based from some Cisco documents in the DocCD. If I find other interesting configuration examples on the Internet that I’d like to “lab out” I’ll be posting them up as well.

The first of (hopefully) many labs to come will be an OSPF point-to-multipoint configruation from Chapter 4 of the study guide. The actual example was modified from an example in Configuring OSPF document from the Cisco website.

Let’s start with the topology:

Here is the dynagen configuration (.net) file:

autostart = False
[localhost]

#

[[7200]]
image = \Program Files\Dynamips\images\c7200-js-mz.123-45.bin
npe = npe-400
ram = 160

#

[[ROUTER R1]]
s1/0 = F1 1
model = 7200

#

[[ROUTER R2]]
s1/0 = F1 2
model = 7200

#

[[ROUTER R3]]
s1/0 = F1 3
model = 7200

#

[[ROUTER R4]]
s1/0 = F1 4
model = 7200

#

[[FRSW F1]]
1:102 = 2:201
1:103 = 3:301
1:104 = 4:401
2:203 = 3:302

Tasks:

  • Configure the serial interfaces with the corresponding IP addresses
  • Configure the ip ospf network point-to-multipoint interface command
  • Configure the encapsulation frame-relay on the interfaces
  • Configure the frame-relay map commands on all the routers to map ip to DLCIs.
  • Configure OSPF

My previous post has the partial configurations. Stay tuned for the rest of my configurations and show command output… ;)

Posted in BSCI Exam Prep, CCNP, Dynamips, Frame Relay, Lab, OSPF, Routing Protocols | 1 Comment » | Print This Post

BSCI: OSPF Network Types (part 2)

Posted by Aragoen Celtdra on 8th August 2008

OSPF over Frame Relay Configuration Options

Types of Frame Relay Topologies:

  • Star Topology
    • aka hub-and-spoke configuration.
    • Remote sites connect to a central site.
    • The central router provides a multipoint connection because it typically uses a single interface to interconnect multiple PVCs.
    • Least expensive type and thus most commonly used topology.
  • Full-mesh Topology
    • All routers have direct connections (VCs) to all other routers.
    • Its the most expensive topology. As more routers are added the more costly it becomes.
    • The formula to determine the number of VCs needed: n(n-1)/2, where n is the number of nodes in the network.
  • Partial-mesh Topology
    • Only some routers have direct access to central site.
    • Cheaper to implement than a full-mesh.

OSPF over NBMA Topology Modes of Operation

To configure OSPF mode, the following interface configuration command is used:

ip ospf network {broadcast | non-broadcast | point-to-multipoint [non-broadcast] | point-to-point}

The following describes the type and parameters used in the ip ospf network command:

Two official modes in NBMA topologies, as described in RFC 2328:

  • Nonbroadcast
    • Simulates the operation of OSPF in broadcast networks
    • Same IP subnet.
    • Neighbors must be configured manually.
    • DR and BDR election is required.
    • DR and BDR need to have full connectivity with all other routers
    • Configuration typically for fully-meshed networks (but can be partial-meshed)
    • Advantage is that it has less overhead traffic as compared to point-to-multipoint.
  • Point to Multipoint
    • Treats the nonbroadcast network as a collection of point-to-point links
    • Routers automatically identify their neighboring routers. Uses a multicast hello packet to automatically discover the neighbors.
    • Do not elect DR and BDR. The router sends additional LSAs with more information about neighboring routers.
    • Configuration typically for partial-meshed, but also used for star topologies.
    • Advantage is that it requires less manual configuration

Cisco Modes of Operation for NBMA Network:

  • Point-to-Multipoint Nonbroadcast
    • Neighbors must be configured manually
    • Does not require a DR or BDR
    • This mode should be used (instead of the RFC-compliant point-to-multipoint mode) if multicast and broadcast are not enabled on the VC.
      • That is because the router cannot dynamically discover its neighboring routers using the multicast hello packets.
  • Broadcast
    • Uses one IP subnet
    • Makes the WAN interface appear to be a LAN
    • Uses a multicast OSPF hello packet to automatically discover neighbors.
    • DR and BDR are elected
    • Full or partial-mesh topology.
  • Point-to-point
    • Each point-to-point connection has a different IP subnet
    • No DR or BDR election required
    • Only used between two routers that need to form an adjacency on a pair of interfaces.
    • Interfaces can either be LAN or WAN.

Defaul OSPF Modes

  • On point-to-point Frame Relay subinterface - point-to-point mode
  • On Frame Relay multipoint subinterface - nonbroadcast mode
  • On a main Frame Relay interface - nonbroadcast mode.

OSPF Broadcast Mode Configuration

Sample configuration:

R1(config)#interface serial 1/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip ospf network broadcast

  • Neighbors must be manually configured on a nonbroadcast mode. Broadcast mode is a workaround for statically listing all existing neighbour routers.
  • The interface is set to broadcast and behaves as though the router connects to a LAN.
  • Because a DR and BDR election is required, make sure to use either a full-mesh topology or a static configuration of the DR based on the interface priority.

OSPF Nonbroadcast Mode Configuration

  • Emulates operation over a broadcast network.
  • All routers should be on the same IP subnet
  • A DR and BDR are elected for the NBMA network
    • DR originates LSAs for the network.
  • Best if the topology is fully-meshed
    • If not fully-meshed, select the DR and BDR manually. The goal is that the selecte DR and BDR have full connectivity to all other neighbors.
  • The LSU packets must be replicated for each PVC. They are sent to each of the interface’s neighboring routers, as defined in the neighbor table.
  • The command to statically define the adjacent relationships in NBMA networks using nonbroadcast mode:

R1(config-router)#neighbor ip-address [priority number] [poll-interval number] [cost number] [database-filter all]

  • The parameters are described as follows:
    • ip-address
      • The IP address of the neighboring router
    • priority number
      • Optional parameter that sets the priority of the neighbor
      • 0 is the default, which means that the neighboring router does not participate in DR/BDR election
    • poll-interval number
      • Optional parameter that sets the length of time (in seconds) that an NBMA interface waits before sending hellos to the neighbors even if the neighbor is inactive.
    • cost number
      • Optional parameter that assigns a cost to the neighbor using any value from 1 to 65535.
      • If now specific cost is configured for a neighbor, the neighbor assumes the cost of the interface based on the ip ospf cost command.
      • For point-to-multipoint interfaces, the cost number keyword/argument parameters are the only options that are applicable
      • This keyword does not apply to nonbroadcast mode.
    • database-filter all
      • Optional parameter that filters outgoing LSAs to an OSPF neighbor.

Using the neighbor command in Nonbroadcast Mode

Router1 Configuration

interface Serial2
ip address 1.1.1.2 255.255.255.0
encapsulation frame-relay
ip ospf priority 2
no keepalive
frame-relay map ip 1.1.1.1 16
!
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
neighbor 1.1.1.1

Router2 Configuration

interface Serial1/0
ip address 1.1.1.1 255.255.255.0
encapsulation frame-relay
no keepalive
clockrate 2000000
frame-relay map ip 1.1.1.2 16
!
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
neighbor 1.1.1.2

  • The ip opsf priority 2 on Router1 sets it as a DR because it has a higher priority value. The only other router (Router2) in this scenario has a default value of, which makes Router2 a BDR
    • To remove Router2 from becoming a BDR, configure an ip ospf priority 0 on Router2’s s1/0 interface.
    • In fact, with multiple routers and no full-mesh topology, set the spoke routers’ priority to 0 to ensure that only the hub becomes the DR - because the hub is the only one that has connectivity to all other routers.
  • Though it is sufficient in this example to configure the neighbor command on one end to form adjacency, it is good practice to configure it on both routers, as shown in the scenario.
  • Additionally, the frame-relay map commands did not need the broadcast parameter because the OSPF packets are unicasted with the neighbor statement.
  • In nonbroadcast mode, neighbor statements are required only on DR and BDR.
  • In a hub-and-spoke topology, neighbor statements must be placed on the hub.
    • The hub must be configured to become DR by assigning a higher priority.
  • It is not mandatory to configure neighbor statements on spoke routers.
  • In a full-mesh NBMA topology, it might be necessary to configure neighbor statements on all routers unless the DR/BDR are statically configured using the ip ospf priority command.
  • The following is what the show ip ospf neighbor would display if ran on Router1.

OSPF Configuration in Point-to-Multipoint Mode (RFC-compliant)

  • RFC-compliant point-to-multipoint mode is designed for partial-mesh or star topology.
    • OSPF treats router-to-router connections as if they are point-to-point links.
    • Multicast packets discover neighboring routers dynmically
  • DRs are not used
  • Type 2 Network LSAs are not flooded.
  • Works by exchanging LSUs that are designed to automatically discover neighboring routers and add them to the neighbor table.
  • Properties of point-to-multipoint mode:
    • Full-mesh network not necessary
      • Two routers can exchange routes without being directly connected. They are, however, connected to a router that has VCs to each of the two routers.
    • No static neighbor configuration
      • Point-to-multipoint mode treats the network as a collection of point-to-point links.
      • Hellos, updates and acknowledgments were sent using multicast. In particular, multicast hellos discovered all neighbors dynamically.
    • One subnet
      • With nonbroadcast mode, point-to-multipoint mode has all routers on the same subnet.
    • Duplicates LSA packets
      • Also similar to nonbroadcast mode, the router replicates the LSU packets and sent out to each of the interfaces neighboring routers.

OSPF Point-to-Multipoint Configuration

Router R1 Configuration

interface serial 1/0
ip address 10.0.0.1 255.0.0.0
ip ospf network point-to-multipoint
encapsulation frame-relay
frame-relay map ip 10.0.0.2 102 broadcast
frame-relay map ip 10.0.0.3 103 broadcast
frame-relay map ip 10.0.0.4 104 broadcast
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0

Router R2 Configuration

interface serial 1/0
ip address 10.0.0.2 255.0.0.0
ip ospf network point-to-multipoint
encapsulation frame-relay
frame-relay map ip 10.0.0.1 201 broadcast
frame-relay map ip 10.0.0.3 203 broadcast

!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0

Cisco Point-to-Multipoint Nonbroadcast mode

  • This is a Cisco extension to the RFC-compliant mode
  • With this mode, neighbors are statically configured, just like nonbroadcast modes.
    • DRs and BDRs are not elected.
  • Modify the neighbor link cost to reflect the different bandwidth of each link.
  • Used for VCs that cannot use multicasts or broadcasts
    • RFC point-to-multipoint mode was developed to support underlying point-to-multipoint VCs that support multicast and broadcast

Using Subinterfaces in OSPF over Frame Relay Configuration

  • Subinterfaces are accomplished by splitting a physical interface into multiple logical interfaces.
    • Each interface can be defined as a point-to-point or a multipoint interface.
    • They were originally created to handle problems with split horizon over NBMA using distance-vector protocols.
    • Each subinterface is a different subnet
    • A point-to-point subinterface is similar to a physical point-to-point link.
    • To define the subinterface use use the global command:

interface serial number.subinterface-number {multipoint | point-to-point}

  • The choice of multipoint or point-to-point affects OSPF operation

Point-to-Point Subinterfaces

  • On a point-to-point subinterface, each VC has its own subinterface.
  • Because it operates just like a physical point-to-point, there is no DR/BDR.
    • Neighbor discovery is automatic
    • Neighbors don’t need to be configured
  • A point-to-point subinterface is usually used with a point-to-point mode, where only two nodes exist on the NBMA network.
  • Each point-to-point connection is a separate subnet.

Multipoint Subinterfaces

  • With this configuration, a single interface has multiple VCs
  • Multipoint Frame Relay subinterfaces default to OSPF nonbroadcast mode.
    • This implies that neighbors need to be statically configured.
    • A DR and BDR are also required.

Resources:

  1. OSPF Design Guide
  2. Initial Configurations for OSPF over Non-Broadcast Links
  3. Adjacencies on Non-Broadcast Multi-Access (NBMA) Networks
  4. Configuring OSPF

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, as well as following the links on the resources section of this entry.

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

A little fun…

Posted by Aragoen Celtdra on 7th August 2008

I just looked through the list of my last few posts and all I saw was “BSCI…” down the list. So, to disrupt the monotony of familiarity, I thought I’d post something off-topic.

Some of you may have seen this before. This is the first time I’ve seen it. Nevertheless, I’m sure it is still fun for either side. The link below should open up a telnet session. If not open up any terminal emulator and point to “towel.blinkenlights.nl”

ASCIImation

And you thought youtube was low-quality!

Posted in Fun | No Comments » | Print This Post

BSCI: OSPF Network Types

Posted by Aragoen Celtdra on 3rd August 2008

OSPF defines three different types of networks based on their physical link types.

Physical Link types:

  1. Point-to-point
    • A network that joins a single pair of routers
  2. Broadcast
    • A multiaccess broadcast network that joins a single pair of routers
  3. Nonbroadcast multiaccess (NBMA)
    • A network that interconnects more than two routers but is not capable of sending broadcast traffic.
    • Examples are:
      • Frame Relay
      • ATM
      • X.25
    • There are five modes of operation for NBMA networks:
      • Nonbroadcast (RFC 2328-compliant mode)
      • Point-to-multipoint (RFC 2328-compliant mode)
      • Point-to-multipoint nonbroadcast (CIsco mode)
      • Broadcast (Cisco mode)
      • Point-to-point (Cisco Mode)

Adjacency Behavior for a Point-to-Point Link

  • A point to point network consists of two routers connecting end to end. A typical example is a T1 serial line configured with PPP or HDLC.
  • The router dynamically detects its neighboring routers by multicasting OSPF hello packets to address 224.0.0.5
  • As long as the pair of routers can communicate directly, they can form and adjacency
  • There is no need for a DR or BDR since there can only be two routers involved.
  • The outgoing interface’s IP address is usually used as the source IP address of the OSPF packets.
  • It is possible to use IP unnumbered interfaces with OSPF.
    • In this case, an IP address of another interface on the router is used as the source IP address.
  • The default OSPF hello/dead intervals are 10/40 seconds.

Adjacency Behavior for a Broadcast Network

  • OSPF routers on a multiaccess broadcast network (Ethernet LAN) forms an adjacency with the DR and BDR on that network.
    • These adjacent routers have synchronized LSDB.
    • When routers first come up on the Ethernet segment, they exchange hello packets and start electing the DR and BDR. The routers then attempt to form adjacencies with the DR and BDR.
  • The DR performs the LSA forwarding and LSDB synchronization task
  • The BDR receives all information that the DR has but does not perform any DR functions while the DR is up. Only if the DR fails will the BDR take over.
    • If DR fails, the BDR immediately becomes DR and an election is held to pick the new BDR
  • The DR and BDR does the following:
    • Reduce routing update traffic
      • Instead of all the routers exchanging information with each and everyone else, they each establish full adjacency with only the DR and BDR.
      • The DR will then send all the information it gathers to each node on the network.
      • This process significantly reduces the flooding process.
    • Manage link-state synchronization
      • The DR and BDR ensure that the other routers on the network have the same link-state information about the network. This process reduces the number of routing errors.

Electing the DR and BDR

  • The DR is the router that has the highest priority value.
  • The BDR has the second highest priority value.
  • The default for the interface OSPF priority is 1
    • When there is a tie on the priority value, the router ID is used.
    • The highest router ID becomes DR
    • The second highest RID becomes the BDR
  • A router that has priority 0 can never be a DR or BDR. These are called DROTHER.
  • If a router with a higher priority joins the network, it does not preempt the DR or BDR.
    • The only time a DR or BDR changes is if one of them is out of service. If the DR is out of service, the BDR takes over as DR and a new BDR is elected.
    • If a BDR becomes out of service, a new BDR is elected.
      • To determine if the DR is out of service, the BDR uses the wait timer. This timer is a reliability feature.
      • If the BDR does not confirm that the DR is forwarding LSAs before the wait timer expires, the BDR assumes that the DR is out of service.

DR and BDR on Each Segment

  • The DR concept happens at the link level.
  • Each network segment has its own pair of DR/BDR in a multiaccess broadcast network.
  • A router can be a DR on one segment and a regular (DROTHER) router on another segment if it is connected to a multiaccess broadcast network.

Setting Priority for the DR election

  • Setting a priority to an interface allows for it to be designated as a DR or BDR on a multiaccess network
  • To configure the priority value, use the following interface configuration command:
    • ip ospf priority number
    • The number value can range between 0 to 255.
  • The DR is the highest priority interface
  • The BDR has the second-highest priority interface
  • Interfaces with priority value set to 0 does not participate in the DR/BDR election, therefore cannot become either.

Example ip ospf priority Configuration:

Router(config)#interface FastEthernet 0/0
Router(config-if)#ip ospf priority 10

  • A DR will not give up its status just because a new interface is reporting a higher priority value.
  • An interface’s priority usually takes effect only if the existing DR fails.
  • Setting an interface to 0, however, takes effect immediately and a new election can take place.

Adjacency Behavior for a Nonbroadcast Multiaccess Network

  • A single router interface can connect to multiple routers. They do not, however, have broadcast capability like we’ve seen with multiaccess broadcast networks.
  • To implement broadcasting or multicasting on a router in a NBMA network, the router replicates the packets to be broadcasts or multicasts and sends them individually on each PVCs to all destinations.
    • This is a CPU-intensive process
    • Additionally, of the NBMA topology is not fully meshed, a broadcast/multicast sent by one router does not reach all the other routers.
  • Examples of NBMA networks are:
    • Frame Relay
    • ATM
    • X.25
  • The default OSPF hello/dead intervals on NBMA interaces are 30 seconds and 120 seconds, respectively.

DR Election in an NBMA Topology

By, default, OSPF cannot automatically build adjacencies with neighbor routers over NBMA interfaces.

The next blog post will cover different types of NBMA topologies and how DR and BDR election is accomplished

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, as well as following the links on the resources section of this entry.

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

BSCI: Verifying OSPF Operations

Posted by Aragoen Celtdra on 1st August 2008

sh ip route ospf Command

  • Displays the OSPF routes known to the router. That is, it verifies the OSPF routes in the IP routing table.
  • One of the best ways to determine connectivity between the local router and the rest of the internetwork.

Figure 1: sh ip route ospf Command

  • O - indicates that the routes was learned from OSPF
  • IA - (Interarea) indicates that the learned route is in a different area
  • The 10.2.1.0 subnet is recognized on Fasthethernet0/0 of this router via neighbor 10.64.0.2
  • [110/65]
    • 110 is the administrative distance of OSPF
    • 65 is the total cost to reach subnet 10.2.1.0

sh ip ospf interface Command

  • Verifies that interfaces are configured in the intended areas.
  • Displays the time intervals, such as hello interval, and shows the neighbor adjacencies.
  • sh ip ospf interface [type number] [brief]
    • type - (Optional) specifies the interface type.
    • number - (Optional) specifies the interface number
    • brief - (Optional) displays brief overview information for OSPF interfaces, states, addresses and masks, and areas on the router.

Figure 2: show ip ospf interface Command

  • The command on the above example details the OSPF status of the FastEthernet 0/0 interface
  • It shows that OSPF is running on this interface including verification that it is in Area 0
  • It also displays other information such as:
    • OSPF process ID - (Process ID 1)
    • Router ID - (Router ID 10.64.0.1)
    • Network Type - (Broadcast)
    • DR - (10.64.0.1)
    • BDR - (10.64.0.2)
    • Hello and Dead timers - (10/40)
    • Neighbor adjacency information - (10.64.0.2)

sh ip ospf neighbor Command

  • Displays a list of neighbors with information for each interface including their:
    • OSPF router ID
    • OSPF priority
    • neighbor adjacency state (such as init, exstart, or full)
    • Dead timer
  • sh ip ospf neighbor [type number] [neighbor-id] [detail]
    • type - (Optional) specifies the interface type
    • number - (Optional) specifies the interface number
    • neighbor-id - (Optional) specifies the neighbor ID
    • detail - (Optional) displays details of all neighbors

Figure 3: show ip ospf neighbor Command Output

  • The first entry shows the adjacency formed on the FastEthernet interface.
    • A FULL state means that the LSDB has been exchanged successfully.
    • The DR entry means that this neighbor is the Designated Router.
      • Another entry that you might see is DROTHER, which means that a router other than this neighboring router is the DR.
      • Notice also that it has a Pri of 1. That refers to the OSPF priority
  • The second line represents Router B’s neighbor on the serial interface.
    • It is neither a DR and BDR because they are not used on point-to-point interfaces (as indicated by a dash [-].
    • Recall also that an OSPF priority of 0 prevents an interface from becoming a DR or BDR. Had this interface been on a broadcast link, the fact that its priority is set to 0 disqualifies it from being elected as DR or BDR.

Figure 4: show ip ospf neighbor detail Command Output

debug ip ospf events Command

  • Used to display OSPF-related events

Figure 5: debug ip ospf events Command Output

  • The output shows that the router received a hello packet on its Fa0/0, interface (sent from the Fa0/0 interface of the neighbor).
  • It also shows this router sending a hello packet on its Fa0/0 interface to multicast address 224.0.0.5

OSPF Router ID

  • An OSPF Router ID (RID) is the router’s OSPF identification in the network.
  • The OSPF routing process chooses a router ID for itself when it starts up.
  • It is a unique ID that can be assigned in several ways, as follows:
    • Highest IP address
      • By defualt, the highest IP address of any physical interface when OSPF starts becomes the router ID.
      • The interface does not need to have OSPF enabled on it. An interface only has to be up for the RID to be assigned.
      • If there’s is no interface with an IP address is up when the OSFP process starts, an error occurs.
    • Loopback Interface
      • If a loopback interface is present, its IP address is always preferred instead of the physical interface’s IP address. That is because loopback interfaces never go down.
      • If there is more than one loopback interface, then the highest IP wins.
    • Manually
      • To configure use the router configuration command:
        • router-id ip-address
      • This method overrides the first two methods.
      • This is also the preferred procedure for setting the router ID.
  • Router ID should be unique
    • No matter how they are configured, router IDs should always be unique throughout the OSPF autonomous system. This is how the OSPF database is able to uniquely describe each router in the network.
    • Remember that every router keeps a complete toplogy database of all routers and links in an area and network. Therefore each router ID being unique helps distinguish them.
    • After the router ID has been set, it does not change, even if the interface that the router is using for the router ID goes down.
      • It only changes if the router reloads or if the OSPF routing process restarts.
  • Loopback Interfaces
    • To assign a Router ID using loopback interface:
      • interface loopback number
    • Overrides the highest IP address on any active physical interface.
    • More stable because they never fail.
    • Can be used for testing (ping) if advertised with the network command.
    • Can use private address to save public IP address usage.
    • A loopback address requires a different subnet for each router, unless the host itself is advertised. By default, OSPF advertises loopback as /32 host routes.
  • router-id Command
    • router-id ip-address
    • Allows to specifically assign a desired router ID.
    • The ip-address can be any unique arbitrary 32-bit address in a dotted decimal format.
    • After it is configured se the clear ip ospf process EXEC command to restart the OSPF routing process, so the router reselects the new IP address as its RID.
      • Caution: this will disrupt an operational network momentarily.

Note: Changing the OSPF router ID of a router whose router ID was set by configuring a loopback interface requires you to either reboot the router or to disable and then enable OSPF. Changing a router ID of a router whose router ID was set by configuring it under the OSPF process requires only that the OSPF process be cleared, a much less drastic move.

show ip ospf

  • Use this command to verify the router ID.
  • This command also displays OSPF timer settings and other statistics, including the number of times the shortest path first (SPF) algorithm has been executed.

Figure 6: show ip ospf Command Output

sh ip protocols

  • Displays IP routing protocol parameters including:
    • Timers
    • Filters
    • Metrics
    • Networks
    • Other information for the entire router

Figure 7: show ip protocols Command Output

debug ip ospf adj

  • Tracks adjacencies as they go up and down

Figure 8: debug ip ospf adj Command Output When a Neighbor Interface Fails

Figure 9: debug ip ospf adj Command Output When a Neighbor Interface Comes Up

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, as well as following the links on the resources section of this entry.

Posted in Uncategorized | 3 Comments » | Print This Post

BSCI: OSPF Basic Configuration

Posted by Aragoen Celtdra on 1st August 2008

Router(config)#router ospf process-id [vrf vpn-name] Enables OSPF process on the router.
Router(config-router)#network ip-address wildcard-mask area-id Identifies which interfaces on the router are part of the OSPF process and the OSPF area to which the network belongs.
  • process ID
    • An ID number used by OSPF internally to identify the OSPF routing process.
    • It does not need to match the process IDs on other routers.
    • Running multiple OSPF processes on the same router creates multiple database instances on the router and can add extra overhead. Therefore it is not recommended.
  • vrf [vpn-name]
    • Specifies the name of the virtual private network (VPN) routing and forwarding (VRF) instance to asspciate with OSPF VRF process.
    • This is an optional paramater.
  • ip-address
    • This parameter can be an ip address of an interface, a network address, or subnet address.
    • This address instructs the router to determine which links to advertise to, which links to check for advertisements, and what networks to advertise.
  • wild-card mask
    • Uses wildcard bits:
      • 0 means a match
      • 1 means don’t care
    • For example, a wildcard mask of 0.0.255.255 means, to match the first two octets and ignore the last 2.
    • 0.0.0.0 means to match the whole address
    • A wildcard mask combination of 0.0.0.0 255.255.255.255 matches all interfaces on the router.
  • area-id
    • Specifies the OSPF area to be associated with the address.
    • Can be a decimal value (such as 1 or 50) or can be a dotted-decimal notation (such as 10.1.1.1)

The Alternative

  • Introduced in Cisco IOS 21.3(11)T, a new method for enabling OSPF on the interface was introduced.
  • Instead of configuring the interfaces in the router configuration mode, you can configure the OSPF process on the interface itself.
  • Because it is configured directly and explicitly on the interface, it takes precedence over the network area command.
  • The command is summarized below:
Router(config-if)#ip ospf process-id area area-id [secondaries none] Configures OSPF directly on the interface
  • process-id
    • ID number that identifies the OSPF process.
    • Can range from 1 to 65535.
  • area-id
    • OSPF area to be associated with the interface.
    • A decimal value that can range between 0 to 4294967295.
  • secondaries none
    • Prevents secondary IP addresses on the interface from being advertised.
    • This parameter is optional.

Single-Area OSPF Configuration Example

Figure 1: Sample OSPF scenario

The following is the screenshot of the configurations:

Figure 2: Router A Configuration

  • Router A’s configuration uses the general statement network 10.0.0.0 0.255.255.255.
    • This method matches all interfaces with IP addresses that start with 10.x.x.x network.
    • It is assigned to OSPF process 1 and area 0.

Figure 3: Router B Configuration

  • The configuration method used for Router B defined the specific host addresses.
  • By using the wildcard mask of 0.0.0.0, the OSPF process is required to match all the defined octets of the address.

NOTE: For OSPF, the network command and its wildcard mask are not used for route summarization purposes. It is used strictly to enable OSPF for a single or multiple interfaces.

Multiarea OSPF Configuration Example

Figure 4: Sample OSPF Multiarea Topology

Following are the screenshots of the configuration for Routers A and B:

Figure 5: Router A Configuration

  • The configuration for Router A in this example stays the same as the previous one above.

Figure 6: Router B Configuration

  • The configuration for area 0 remain the same as the previous one (i.e. using the traditional network statement)
  • The configuration for area 1 uses the new alternative of enabling OSPF on the interface itself by using the interface configuration ip ospf 50 area 1.
    • The traditional alternative would have been a router configuration of network 10.2.1.2 0.0.0.0 area 1.

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, as well as following the links on the resources section of this entry.

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

 

Warning: stristr() [function.stristr]: Empty delimiter in /home/liwanagf/public_html/routemyworld/wp-content/plugins/wassup/wassup.php on line 2093