Not a banner evening for me here. The work week was killer, and I’m pretty burnt out right now. I got in about 2 hours worth of rack time, and did make a lot of progress, in some ways. I learned a lot of things tonight, details about OSPF configuration, specifically. More accurately, I reviewed a lot of things I knew and understood, but couldn’t regurgitate without looking up some information first. But as far as scenario tasks, all I managed to accomplish was the OSPF configuration. I was beating on it like a bulldozer, mostly fumbling around getting it to behave like it should have over the frame-relay network. And I did. And it’s right. And I understand it. But it was rough going. The other thing I got done tonight was to strategize my redistribution approach. I know what I have to do now, or least what I THINK I have to do, until something I didn’t think about yet pops up. That’s tomorrow’s issue, though…
I have figured out that you MUST know everything there is to know about OSPF link types, period. No great revelation, but an important realization nonetheless. If the scenario wants you to set up the neighbor relationship with a default hello time of 10 but no DR/BDR, then you have to know that the type is point-to-point. And if the scenario will require subinterfaces to be advertised as host routes for anything to work because of some screwed-up frame/layer 2 topology, then you have to know that the type is point-to-multipoint. Etc. You just have to know that stuff, off the top of your head, no question about it.
I figure by the time I’m done with 25 practice labs, I’ll have a really good handle on these things. I hope, anyway. I’m only on scenario 3, but I’m already putting to good use information I picked up in the first 2 scenarios. I’m smarter about how to approach redistribution. I’m smarter about what it takes to make the frame-relay nodes talk to one another (although I need to review the inverse-arp process). But man, there’s so much information to command – to OWN. To make mine.
In the first 2 scenarios, I peeked at the answer key more than I should have. I’m refusing to do that this time. I’m thinking about each scenario as if it were the real lab. If I was stuck on the real lab, where can I turn? To http://cisco.com/univercd. So that’s what I’m doing, forcing myself to learn all the drill-downs so that I know where to find things. If I am absolutely stumped, then I’ll take a look at the answer key to get headed in the right direction.
Tonight, that stumper was a requirement for a particular network originating in one OSPF area to show up neither in the routing table nor OSPF database of a router in a different OSPF area. I know that if you want to keep an OSPF route from hitting the routing table, you can filter the routes with a distribute list. The prefix will still show up in the OSPF database, since the distribute list doesn’t filter LSAs. So that’s easy enough. But if you want to keep the prefix not only out of the routing table, but also out of the OSPF database, that means you have to filter LSAs.
OSPF ABR Type 3 LSA Filtering is an IOS feature that allows you to filter LSAs at an area border router.
- Connect to the ABR.
- Build a prefix-list. The prefix-list should deny the prefix(es) you want to filter, and permit everything else.
- In the router ospf paragraph, apply the prefix list to advertisements flowing inbound, from the perspective of the area. You apply the filter “in” for LSAs that the ABR will be injecting into the area. You apply the filter “out” for LSAs that the ABR will be receiving from the area.
- Code example:
ip prefix-list drop10nets seq 10 deny 10.0.0.0/8 le 32
ip prefix-list drop10nets seq 20 permit 0.0.0.0/0 le 32
router ospf 1
area 57 filter-list prefix drop10nets in
- In this example, we create a prefix list called “drop10nets”. This prefix list will drop any subnet that falls within the 10.0.0.0 address space. The first line means literally to deny any network that falls within 10.0.0.0/8 who has a prefix that’s less than or equal to 32 bits. In other words, anything from host routes on up – if it starts with 10 dot, we’re going to drop it. In the next line, we permit everything. Then in the OSPF paragraph, we instruct the ABR to filter the LSAs according to the drop10nets prefix-list for link-state advertisements that the router is sending into area 57.
- If you have more than one ABR for a given area, you’d need to perform this filtering on each ABR to keep the LSAs out of the area.
Read more about ip prefix-lists. Note that this falls under “BGP Commands”, even though prefix-lists are used more broadly than just for BGP.