From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 11

780 Words. Plan about 5 minute(s) to read this.

This chapter of the OECG covers IGP route redistribution, route summarization and default routing. That’s a wee bit long to put into the blog article title, so I abbreviated to “Redistribution, Etc.” If you don’t like it, sue me. :-) It’s not a terribly long chapter, covering only 33 pages of hard content. But as I browsed through it, there’s LOTS of text and lists of items, and not so much taken up with diagrams. So it’s a power-packed chapter. Think fudge, not angel-food cake.

So off we go for the first topic of the week, route maps. Route maps provide a way for the router to examine packets and make forwarding (and other) decisions based on something other than just the destination address and RIB. Route maps allow you to apply if/then/else logic to a routing decision. Packets that “match” criteria you define in the route-map can be “set” with various attributes.

  • Route maps have specific names. All commands using that name are a part of the same route map.
  • Route maps, similar to access lists, have actions: permit or deny.
  • Route map commands are sequenced, which you can leverage to insert route-map commands where you like.
  • A redistribution route-map processes what routes to redistribute based on the routing table at that moment.
  • Like an access-list, a route-map is processed in order based on the sequence numbers.
  • In the context of redistribution, when a route is matched by a route-map command, no more commands are precessed.
  • In the context of redistribution, if there’s a route match with a “permit”, the route is redistributed. (Ergo, whether or not the route-map statement has a permit is the key. If the route map permit statement calls an ACL with both permits and denys, an ACL deny will cause the route in question to fall to the next statement of the route map, not be rejected out of hand. So what you’re really saying is, “If the route in this ACL is permitted, do whatever the route-map statement says to do. If the route-map statement says permit, then redistribute the route. If the route-map statement says deny, then that route is dropped from further consideration for redistribution.”)
  • In the context of redistribution, if there’s a route match with a “deny”, the route is not redistributed.
  • If you want a route-map statement to match all, use a route-map statement with a permit action, but not a match command. Otherwise, be aware that there’s an implied deny all at the end of the route map.

You’ve got a lot of flexibility when choosing how to match routes. There’s a number of criteria available to you:

  • You can match a route based on the route’s outgoing interface with “match interface”.
  • You can match a route based on the route’s prefix and length with a “match ip address” command, referencing an ip prefix-list.
  • You can match a route based on the route’s next hop, using the “match ip next-hop”.
  • You can match a route based on the route’s advertising router, using the “match ip route-source” statement.
  • “Match metric” allows you to match a route based on the route’s metric (bet you wouldn’t have guess that unless I told you, right?)
  • To match a route based on type (internal, external, etc.), use the “match route-type” statement.
  • Presuming a tag has been set, you can match based on the “match tag” statement.

Now, when redistributing routes using a route map, not only can you match based on the criteria above, but you can also manipulate the route before redistributing it. (From personal experience, this can be VERY useful for setting metrics, especially if you’re redistributing the same route from multiple routers and need to be sure that one route is preferred over the other. Getting your metrics right is important.) Here are some things you can set when redistributing the routes:

  • “set level” where you can set “level-1, level-2, level-1-2, stub-area, backbone” allows you to define which database the route is redistrbuted into. (A better explanation of this is that it “Sets the IS-IS level or the OSPF area into which a matched route is to be redistributed.” Taken from a Ciscopress quotation I found while googling for an explanation.)
  • “set metric” sets the route metric for OSPF, RIP and IS-IS.
  • “set metric bandwidth/delay/reliability/loading/mtu” sets metric for (you guessed it) IGRP or EIGRP. Hint – if your K values are the defaults of only bandwidth and delay, then the rest don’t matter, although you can set them without hurting anything.
  • “set metric-type” sets the type of route for OSPF and IS-IS.
  • “set tag” allows you to set a tag value in the route.