Route map with continue clause

[verma-rohit]

Hello,

I was experimenting with route-map with continue clause, however the use of continue clause does not set well with my understanding of its processing.

1. A route matches a match statement execute its configured set values and then jumps to other sequence number as per configured continue statement.

2. If next route-map sequence has no match statement, it should execute configured set action.

1. Access and Core are OSPF neighbors. 

2. On Core: 

Core#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.6       1   FULL/DR         00:00:39    10.0.128.2      GigabitEthernet0/2
Core#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      192.168.0.0/32 is subnetted, 3 subnets
O        192.168.0.6 [110/2] via 10.0.128.2, 00:39:07, GigabitEthernet0/2
O E2  192.168.1.0/24 [110/20] via 10.0.128.2, 00:39:07, GigabitEthernet0/2
      192.168.2.0/32 is subnetted, 1 subnets
O E2     192.168.2.1 [110/20] via 10.0.128.2, 00:39:07, GigabitEthernet0/2
Core#
Core#

3. On Same Core, I have BGP configured to perform OSPF route  redistribution:

OSPF route on Core with TAG 2001
Core#show ip route 192.168.2.1
Routing entry for 192.168.2.1/32
  Known via "ospf 64501", distance 110, metric 20
  Tag 2001, type extern 2, forward metric 1
  Redistributing via bgp 64501
  Advertised by bgp 64501 route-map OSPF2BGP
  Last update from 10.0.128.2 on GigabitEthernet0/2, 00:50:55 ago
  Routing Descriptor Blocks:
  * 10.0.128.2, from 192.168.0.6, 00:50:55 ago, via GigabitEthernet0/2
      Route metric is 20, traffic share count is 1
      Route tag 2001

Core#sh run | s r b
router bgp 64501
 bgp router-id 192.168.0.5
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 description Client
 neighbor 10.0.0.5 remote-as 64500
 neighbor 10.0.0.5 description eBGP to Upstream
 !
 address-family ipv4
  network 10.0.0.0 mask 255.255.0.0
  network 192.168.0.5 mask 255.255.255.255
  redistribute ospf 64501 route-map OSPF2BGP
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 send-community
  neighbor 10.0.0.2 next-hop-self
  neighbor 10.0.0.2 route-map FromClient in
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 send-community
  neighbor 10.0.0.5 next-hop-self
 exit-address-family
Core#

4. Route-map on Core

Spoiler

Core#show route-map OSPF2BGP
route-map OSPF2BGP, permit, sequence 10
  Match clauses:
    route-type external 
     tag 2000 
  Continue: to next entry 11
  Set clauses:
    community 64501:2 additive
    origin egp 64501
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2BGP, permit, sequence 11
  Match clauses:
    route-type external 
  Continue: to next entry 20
  Set clauses:
    community 64501:2001 additive
    origin igp
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2BGP, permit, sequence 20
  Match clauses:
  Set clauses:
    weight 200
  Policy routing matches: 0 packets, 0 bytes
Core#

Result:

On core, I anticipated BGP attributes for route 192.168.2.1 to have:

1. community 64501:2001 and origin as IGP

2. As there is continue configured on in seq 11, control moves to seq 20 and assign weight 200.

However , seq 20 is never executed it seems. Any reason why ?

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

[Georg Pauwen]

I agree with Paul and Giuseppe. Nowhere is this documented, so you kind of have to conclude that it doesn't work in redistribution just by trial and error. I have spent a good amount of time searching but could not find a single mention of this restriction anywhere...

The good thing is: now we know !

How would one proceed to get Cisco to include this in the documentation ?

[paul driver]

Hello

---

@verma-rohit wrote:

Hello,

2. If next route-map sequence has no match statement, it should execute configured set action.

FYI - TAGs don’t work with route-map redistribution into bgp, Communities are the equivalent.
As the match clause in stanza 10 was on external routes and the tags are not applicable then the router will just read the match clause which basically has no set statement.
I would assume the continue 11 will work however there isn't anything else to match upon because this was performed in stanza 10, if you tried to match on another prefix that isnt in the first match from stanza 10 then it should read stanza 11 but at this time there isn’t any else to match on .

Try the following and see if the community  64501:2 works for 192.168.2.0/24

neighbor 10.0.0.2 send-community both
neighbor 10.0.0.5 send-community both

ip prefix-list 10 permit 192.168.1.0/24

route-map OSPF2BGP permit 10
match ip address prefix-list 10
continue 11
set tag 2000  < …………. doesnt work

route-map OSPF2BGP permit 11
set community 64501:2 additive

[verma-rohit]

Hi Paul,

Thanks for your feedback. 

FYI - TAGs don’t work with route-map redistribution into bgp, Communities are the equivalent.

I have another E2 route on Core , 192.168.1.0 with a TAG of 2000 and it matched seq 10 for redistributed into BGP.

Core#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24
  Known via "ospf 64501", distance 110, metric 20
  Tag 2000, type extern 2, forward metric 1
  Redistributing via bgp 64501
  Advertised by bgp 64501 route-map OSPF2BGP
  Last update from 10.0.128.2 on GigabitEthernet0/2, 02:29:26 ago
  Routing Descriptor Blocks:
  * 10.0.128.2, from 192.168.0.6, 02:29:26 ago, via GigabitEthernet0/2
      Route metric is 20, traffic share count is 1
      Route tag 2000

Core#
Core#show run | sec OSPF2BGP
  redistribute ospf 64501 route-map OSPF2BGP
route-map OSPF2BGP permit 10
 match tag 2000
 match route-type external
 continue
 set origin egp 64501
 set community 64501:2 additive
route-map OSPF2BGP permit 11
 match route-type external
 continue
 set origin igp
 set community 64501:2001 additive
route-map OSPF2BGP permit 20
 match route-type external
 set weight 200
Core#


Core#show ip bgp 192.168.1.0
BGP routing table entry for 192.168.1.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     5         
  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

Now continue in Seq 10 would allowed Seq 11 to execute as well and based on text which i shared in initial post, should have  overwritten origin code and community value but it wasn't to be. 

I will test the script which you asked me to configure and share my feedback. 

[paul driver]

Hello
I could have made myself a bit clearer, You can match on a tagged ospf prefix that is to be redistributed into bgp but setting a tag then this wont work, And ive just realized you are indeed matching on a tag so my mistake, So referring back to your own OP for route-map stanza 11 ,the resulting logic would be the external ospf prefix 192.168.2.0 /24 with a tag 2001 should be set an origin IGB with a community PA of 64501:2001 which looks correct from your OP post.

10.0.128.2 from 0.0.0.0 (192.168.0.5)
      Origin IGP, metric 20, localpref 100, weight 32768, valid, sourced, best
      Community: 64501:2001

The reason for this would be that in stanza 10 a match is made on both external routes and tag of 2000 for 192.168.1.0/24 but not 192.168.2.0/24 then the continue is adhered in stanza 11(next stanza as no number is specified) where again a match is made on specifically any external routes that was not matched in the previous stanza and by time you get to the last stanza 20 all of the external routes have already been matched but with the continue the set command should be applied.