Baby, You Can Route My World!

I’m about to smack a helpless dog from all this frustration. I’ve been trying to create an ipsec tunnel between a PIX and an Edgewater device on a remote location since yesterday and I’m not getting anywhere. Checked all my configs and checked them twice five times. Hmmmm………

Just kidding about smacking a helpless dog - for you dog-lovers out there. I meant to say a helpless cat.

I just finished another remote site in Arkansas tonight, adding it to the list of routers I have successfully configured with ipsec vpn. And each time I add another crypto map and tunnel-group entry into the PIX, the more natural it becomes. It feels nice to see that continous ping finally show “Reply…” instead of the dreaded “Request timed out”. It’s also a fist-pumping moment to see that the tracert result shows that it is now using the new tunnel instead of the old.

In addition I successfully configured RADIUS authentication for our VPN client users today at work. I can add that now to my resume of small accomplishments .

I should have finished earlier but I was also watching a local high school football game on ESPN2. Normally I don’t watch hs football but two future recruits for the USC Trojans were playing on each side. But I really wanted to see more of how well the much-hyped future Trojan quarterback, Matt Barkley, was going to perform. He happens to be the first junior to ever be awarded the Gatorade national football player of the year. They ended up winning in triple OT, despite a three interception performance from Barkley. Oh yeah, he also happens to go to Mater Dei HS, the same program where previous Heisman trophy winning Trojan QB Matt Leinart went. So yeah, add another one to the win column… Not that anyone cares.

What a trip this last few weeks have been. I have mentioned previously that I have been busy with some cool implementation projects at work. Specifically, I have been tasked to configure our PIX appliance to accept remote VPN client requests. This is a very interesting and fun project for me because I have never done any of these before. I have never even been inside a pix OS nor even seen one in my IT career. I have mentioned before that aside from the few good years where I maintained and implemented a Windows Active Directory infrastructure at my old job, most of my career was relegated to doing menial help desk support - something I’ve made a decision to change. And nine months after a made that decision, I’m finally seeing that change.

Last week I was able to finally see my work bear some fruits - in a matter of saying. I now have remote users from our company hitting our pix and able to access local resources in our corporate office (thanks to Barry of bitbucketblog.com, in part). There’s still a lot of work I need to do to clean up my configurations but seeing my implementation actually working is a big boost on my confidence.

Some of the things I need to clean up for sure is the routing. Everything so far is static (which is fine for our purposes since we don’t have a lot of routers or sites that need dynamic routing.) But it would be nice to have OSPF running later. Also, right now, the users authenticate against a local username/password on the pix appliance. Ideally, we would like them to authenticate on a Windows RADIUS server.

Despite all that, though, I already learned a ton of things. Some things I’ve never used before but now understand a little better:

• What IPsec is all about
• Configure ISAKMP parameters
• Configure IPsec parameters
• Crypto maps
• Dynamic crypto maps
• NAT
• NAT-T
• Split-tunnels
• Better understanding of IP access-lists
• Reverse Route Injection
• a few more that I probably am not remembering

Now I still can’t say that I understand them well. But at least I have a better idea of what these things are all about. And with time and experience, I can develop a more solid understanding of them. In fact, learning how to do the step by step configuration was pretty easy. The real challenge is to really understand everything behind all the commands I was typing in. And for the most part, I took particular attention to what I was asked to type in by the Cisco documentations. I’ve downloaded and printed out thousands of pages of Cisco docs to peruse to better understand what I was doing. I’ve spent late nights and weekends reading for hours on every configuration command that was asked of me. Needless to say, my brain is packed with information that I’m sure I will forget 75% of. But that’s ok. There’s absolutely no doubt in my mind that I’ve learned something valuable. In fact, I printed out the running configs on my routers and pixs and I can honestly say that I can read them in a whole new light because of my new understanding. And that my friends is pretty exciting.

Oh by the way, last Thursday, prompted by a renewed confidence in me, my boss asked me if I was up to tearing down our old router-to-router gre tunnels to our remote sites and configure a multiple router-to-pix ipsec vpn tunnels to replace the old one. Not wanting to miss out on the opportunity I immediately said, “hells yeah!” Much of the initial configuration was very similar to the client configurations so I thought I can fumble my way around it. It turns out that my boss’s confidence in me was a little bit pre-mature because I failed miserably. In fact, I think he might have gotten a little annoyed in me for being so confident that I could do it. He told me at first that if I wasn’t comfortable, that I should tell him right then and there when he asked me. I wanted to do it so bad, partly to get the “hands-on” and partly to show him initiative and that I can do it. But it proved to be a little bit over-whelming as I worked on it from 8am to 9pm almost non-stop that day only to end up breaking things. In the end my boss told me to go home and no to touch the routers any further. A little bit dejected and hit with a little dose of you-are-way-in-over-your-head reality I went home and cracked open a thick binder of documentations I printed from work and dug in through the steps and looked for what I was doing wrong.

The next day the boss ( a former CCIE, but years separated from hard core IOS hands on) was in his office with his room door shut working away at fixing some of the configs I broke. That whole day sure felt very long and uncomfortable and I knew my boss was not particularly happy because he was short with me when I ask him questions. So I just sat in my corner and used every opportunity to continue researching on what I did wrong. I was just resigned to let things be with an almost nonchalant “oh well” attitude. By the end of the day, my boss has not succeeded in getting the configuration running and the deadline to get the tunnel up was at the end of that day because the primary Internet circuit that the current tunnel is running on is about to get turned down at the end of business day. To make things worse he had to leave early that day. So, faced with frustration of the whole day, my boss turned to me again and told me to look through his configuration because he has been looking at it all day and tunnel vision (pun) has impaired his brains that he is having a hard time spotting little mistakes that he might have made but otherwise could not spot. He told me what to look for and I started looking at the configurations line by line. Much to my surprise, or non-surprise, most of the configuration he put in there were very similar to what I had initially configured. In fact they were pretty much the same ones minus a few changes (e.g. where I configured a 3des, he put in a des or where i put in an md5 hash, he substituted a sha). I even spotted an acl that he configured that I thought was not right.

And so thinking that nothing else could possibly go more insane, I cleared all his configurations - with his approval, of course (or so I interpreted something he said as approval ;)). And with the notes that I jotted down from the night before and all through the day, I rebuilt the configuration… And what do you know! A few hours of careful and meticulous reconfiguration, I finally got one tunnel up and endpoints talking to each other. In the process of him fixing my mess, he also broke the client vpn configurations I made earlier that week. But I was also able to reconfigure it back to its proper working order. I tested all the routing and ping and traceroute outputs were flying back and forth. I felt vindicated. Actually, I wanted to say out loud in a sinister tone, “vengeance is mine!” but that didn’t feel quite right. After that, configuring all the other routers were cake.

Now I can’t claim that I’m smarter than my boss or anything. Because 999 times out of 1000, he will out-configure me. He is also 100 times smarter than me.  But I can’t say that I got lucky either, because this has nothing to do with luck. It’s either configured correctly or not. Maybe it was more of him being unlucky just for that day that allowed me to out-do his work

Looking back, I don’t know what it is that I did wrong the first time around that I didn’t do this time that made it work or vice versa. The irony is that, I found what was wrong with his configuration which I worked to resolve. I guess if he hadn’t changed the configs that allowed me to see something that didn’t look right, I wouldn’t have had the werewithal to change it again for fear of breaking anything further. Change is good.

In the end, I have a pix authenticating remote vpn clients and three remote sites configured with router-to-pix tunnel up and running. And all that was done on a production network by an (almost)engineer with nearly no experience or business being on a router. In any other environment, I might not have had this opportunity. But one thing is for sure, whether the opportunity is there or not, I learned that you must always be prepared and constantly train yourself by reading, asking, testing, tinkering, labbing, etc. Because when real opportunity comes, you’d have already armed yourself with the ability to say “yes” to that opportunity, even though you might not feel entirely ready.

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:
August 22nd, 2008 at 10:17 am eHave 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.

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.)

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

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…

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
   • OSPF Configuration Examples

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!

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