One of my ExpertExpress engagements focused on BGP route maps and setting BGP attributes based on BGP communities, so I wanted to brush up my RouteMapFoo before the online session.

Here are a few (not-so-unexpected) results gathered from IOSv release 15.5(3)M.

TL&DR: The continue feature works only in route maps applied to BGP neighbors.

Test setup

I built a four node network in VIRL representing an ISP network with an upstream provider, access network running OSPF with the core network, and a BGP client:

The VIRL file describing the topology (including working router configurations) is in my VIRL GitHub repository.

The access router is redistributing static routes pointing toward customers into OSPF and copying static route tags into OSPF tags:

router ospf 64501
 redistribute static subnets
 passive-interface Loopback0
!
ip route 192.168.1.0 255.255.255.0 Null0 tag 2000
ip route 192.168.2.1 255.255.255.255 Null0 tag 2001

Nice surprise: automatic copy of route tags from static routes to OSPF external routes works:

Access#show ip ospf database external

            OSPF Router with ID (192.168.0.6) (Process ID 64501)

Type-5 AS External Link States

  LS age: 742
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.1.0 (External Network Number )
  Advertising Router: 192.168.0.6
  LS Seq Number: 80000001
  Checksum: 0x21CD
  Length: 36
  Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 2000

  LS age: 660
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.2.1 (External Network Number )
  Advertising Router: 192.168.0.6
  LS Seq Number: 80000001
  Checksum: 0xCE0
  Length: 36
  Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 2001

Redistribution route maps

Next test: redistribute OSPF routes into BGP with a route map to set BGP attributes in the redistribution point.

In the redistribution route-map I wanted to:

• Set origin to IGP and add BGP community 64501:1 for internal OSPF routes;
• Set origin to EGP 64501 and add BGP community 64501:2 for external OSPF routes;
• Add BGP community 64501:2000 for external OSPF routes with tag 2000.

Before you ask: I had no really good reason to do that, but my customer was using something along the same lines, so I wanted to test all potential combinations.

This would be the ideal route-map to do that:

route-map OSPF2BGP permit 10
 match route-type external
 continue
 set origin egp 64501
 set community 64501:2 additive
!
route-map OSPF2BGP permit 11
 match route-type internal
 continue
 set origin igp
 set community 64501:2001 additive
!
route-map OSPF2BGP permit 20
 match tag 2000
 set community 64501:2000 additive

Caveat#1: EGP keyword is hidden in recent IOS releases (I’d consider that a good thing). It still works, but it won’t show in context-sensitive help.

I also stumbled upon two limitations of route maps used to control redistribution of routing information between routing protocols:

Caveat#2: You cannot use set community additive in a redistribution route-map

Caveat#3: You cannot use continue clause in a redistribution route-map.

The lack of support for continue clause was somewhat expected after reading the relevant IOS documentation, and without the continue clause it makes no sense using set community additive in a redistribution point (where source routes have no BGP communities).

In both cases Cisco IOS warns you when configuring redistribution with redistribute route-map command:

Core(config)#router bgp 64501
Core(config-router)#addr ipv4
Core(config-router-af)#redist
Core(config-router-af)#redistribute ospf 64501 route-map OSPF2BGP
% "OSPF2BGP" used as redistribute ospf into bgp route-map, continue match not supported
% not supported match will behave as route-map with no match

I had to rewrite the route map with entries matching each combination of the OSPF attributes (obviously starting with the most-specific scenarios first) and setting all desired BGP communities in one route-map entry:

route-map OSPF2BGP permit 10
 match tag 2000
 match route-type external
 set origin egp 64501
 set community 64501:2 64501:2000
!
route-map OSPF2BGP permit 20
 match route-type external
 set origin egp 64501
 set community 64501:2
!
route-map OSPF2BGP permit 30
 match route-type internal
 set origin igp
 set community 64501:1

It’s ugly but at least it works:

Core#show ip bgp 192.168.1.0
BGP routing table entry for 192.168.1.0/24, version 19
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  Local
    10.0.128.2 from 0.0.0.0 (192.168.0.5)
      Origin EGP, metric 20, localpref 100, weight 32768, valid, sourced, best
      Community: 64501:2 64501:2000
      rx pathid: 0, tx pathid: 0x0
Core#show ip bgp 192.168.2.1
BGP routing table entry for 192.168.2.1/32, version 20
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  Local
    10.0.128.2 from 0.0.0.0 (192.168.0.5)
      Origin EGP, metric 20, localpref 100, weight 32768, valid, sourced, best
      Community: 64501:2
      rx pathid: 0, tx pathid: 0x0

In the worst case, the limitations on redistribute route-maps result in a Cartesian product of all possible match conditions. Definitely not something I’d want to configure manually. Is anyone aware of a tool that would generate route-maps with all possible combinations of match criteria automatically?

Network origination route-maps

I tried to use a slightly different approach on the client router: insert static routes into BGP using network statement with a route-map option.

router bgp 65001
 bgp router-id 192.168.0.9
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 64501
 neighbor 10.0.0.1 description eBGP to Core
 !
 address-family ipv4
  network 192.168.11.0 route-map Static2BGP
  network 192.168.12.1 mask 255.255.255.255 route-map Static2BGP

Caveat#1: The continue feature doesn’t work when using a route map in a network statement.

Caveat#2: Cisco IOS doesn’t even complain.

However, there were also some good news:

• Matching static route tags works;
• You can use set community additive command (although it doesn’t do you much good if you can’t use continue command).

Inbound BGP Neighbor Route Maps

Finally, I wanted to test whether the continue feature works in inbound route maps applied to individual BGP neighbors. Here’s what I wanted to achieve:

• Set MED of all incoming routes to 75;
• Set local preference of routes with community 64501:2000 to 2000
• Prepend remote AS to routes with community 64501:3

Here’s the route map I used:

ip community-list standard ClientPrepend permit 64501:3
ip community-list standard ClientLocPref permit 64501:2000
!
route-map FromClient permit 10
 continue
 set metric 75
!
route-map FromClient permit 20
 match community ClientPrepend
 continue
 set as-path prepend last-as 3
!
route-map FromClient permit 30
 match community ClientLocPref
 set local-preference 10

It worked without a glitch ;)

Summary

Here’s the summary of how some route map features work in Cisco IOSv release 15.5(3)M (I didn’t test route maps applied to outbound BGP route updates – that worked from day one):

	Matching tags	Adding communities	Route-map continue
Route redistribution	Yes	No	No
BGP origination with network statement	Yes	Yes	No
Processing inbound BGP updates	N/A	Yes	Yes
Processing outbound BGP updates	N/A	Yes	Yes