Playing with RIP on ASA

Mon 23 August 2010 in Cisco

#Cisco

Cisco ASA and RIP
RIP has been with ASA for years and in this article I will try to cover all possible scenarios in configuring, misconfiguring. debugging and verifying it. As I come up with new ideas how to break the RIP on ASA I will update this article as well. As it would be expected ASA has a bit limited version of RIP daemon as compared with IOS one. Major tasks you my be required to do :

Enable RIP on the ASA;
Dictate the version to work with – RIP v1 or RIP v2;
Specify networks RIP protocol will be active for;
Exclude some interfaces from active advertising RIP on them but allow to get
RIP updates on them , i.e. passive interface(s);
Decide whether you want auto-summarization or not. Default is on;
Enable Rip updates authentication and whether it should be encrypted (MD5 mode) or clear text (text mode);
If using authentication define authentication keys under relevant interfaces;
To make your life harder you will be asked to redistribute;
Finally verify and debug RIP operation.

SO let’s get our hands dirty.

Enable RIP routing process.

ASA#conf t
ASA(config)# router rip   
TokyoASA(config-router)#

Set it to run exclusively version 2 . ASA doesn’t know to mix version 2 and 1 as IOS does.

TokyoASA(config-router)# version 2

Networks to be active for . You should specify classful nets or even if you specify anything different after you enter such networks ASA will automatically turn them into classful ones anyway.

TokyoASA(config-router)#  network 5.0.0.0

Verifying configuration so far:

TokyoASA(config-router)# sh run router
router rip
 network 5.0.0.0   
 version 2

You will most probably want to disable summarization :

TokyoASA(config-router)# no auto-summary

Exclude some interface from advertising on it:
- To suppress on ALL interfaces in one go:

TokyoASA(config-router)# passive-interface  default

To be more specific:

TokyoASA(config-router)# passive-interface  outside

Authentication is configured exclusively under the interface : - Dictate which authentication mode to use.

TokyoASA(config-if)# rip authentication mode md5

Specify the key (password) and its id.

TokyoASA(config-if)# rip authentication key MYKEY key_id 33

Here is how it looks in show run interface :

interface Ethernet0/0   
 nameif outside   
 security-level 0   
 ip address 136.6.12.12 255.255.255.0   
 rip authentication mode md5   
 rip authentication key <removed> key_id 33

Redistribute. Just redistributing learned in other ways networks into the RIP would be boring. As usual you redistribute connected, static, ospf and rip (when working with the rest of the protocols).

TokyoASA(config-router)# redistribute ? 
router mode commands/options:   
  connected  Connected   
  ospf       Open Shortest Path First (OSPF)   
  rip        Routing Information Protocol (RIP)   
  static     Static routes

Much more interesting is to implement some policy while redistributing using route-maps. As expected route-maps here are not what we used to know in IOS. So what can you match for me ?

TokyoASA(config-route-map)# match ? 
route-map mode commands/options:
  interface   Match first hop interface of route    
  ip              Match IP address or next-hop or route-source   
  metric       Match metric of route   
  route-type  Match route-type of route

The most familiar and useful match on ACL lies here:

TokyoASA(config-route-map)# match ip ? 
route-map mode commands/options:    
  address       Match address of route or match packet   
  next-hop      Match next-hop address of route   
  route-source  Match advertising source address of route

TokyoASA(config-route-map)# match ip address FILTER-ACL   

TokyoASA(config-route-map)#  route-map RIPv2 permit 10    
match ip address FILTER-ACL    
match interface inside   

TokyoASA(config-router)# redistribute connected  route-map RIPv2 metric 13

About rest of the match conditions, I’ll cover them when talking about OSPF in ASA.

TokyoASA(config-route-map)# match route-type ? 
route-map mode commands/options:   
  external       Match external route (OSPF type 1/2)   
  internal       Match internal route (including OSPF intra/inter area)   
  local          Match locally generated route   
  nssa-external  Match nssa-external route (OSPF type 1/2)

Filtering out routes in updates.
If you want to filter some networks in updates use distribute-list.

TokyoASA(config-router)# distribute-list MYACL ? 
router mode commands/options:   
  in   Filter incoming routing updates   
  out  Filter outgoing routing updates

Now some debug is due.
Enable rip debug:

TokyoASA1# debug rip
TokyoASA1# sh debug

debug rip routing   
debug rip database   
debug rip events

Normal functioning protocol debug output:

add 10.0.2.0 255.255.255.0 via 0.0.0.0, connected metric [0/0]network
0.0.6.136 is now variably masked   
add 136.6.0.0 255.255.0.0 via 0.0.0.0, connected metric [0/0]   
RIP-DB: redist 10.0.0.0 255.255.255.0(metric 0, last interface dmz1) to RIP   
RIP-DB: redist 10.0.2.0 255.255.255.0(metric 0, last interface dmz1) to RIP   
RIP-DB: Get redist for network 10.0.2.0   
RIP-DB: adding 10.0.2.0 255.255.255.0 (metric 0) via 0.0.0.0 on Ethernet0/2.120 to RIP database   
RIP-DB: rip_create_ndb create 10.0.2.0 255.255.255.0, (best metric 4294967295)   
RIP-DB: rip_create_rdb Create 10.0.2.0 255.255.255.0, (metric 0) via 0.0.0.0, Ethernet0/2.120(permanent)   
RIP-DB: add 10.0.2.0 255.255.255.0 (metric 0) via 0.0.0.0 on Ethernet0/2.120 (donot_age)   
RIP-DB: Adding new rndb entry 10.0.2.0 255.255.255.0   
RIP-DB: rip_create_ndb create 10.0.0.0 255.0.0.0, (best metric 4294967295)   
RIP-DB: rip_create_rdb Create 10.0.0.0 255.0.0.0, (metric 0) via 0.0.0.0, Null0(permanent)   
RIP-DB: Created rip ndb summary entry for 10.0.0.0 255.0.0.0   
RIP-DB: Adding new rndb entry 10.0.0.0 255.0.0.0 rip_route_adjust for dmz1 coming up   
RIP: sending request on dmz1 to 224.0.0.9 rip_route_adjust for dmz1 coming up   
RIP: sending request on dmz1 to 224.0.0.9   
RIP: sending v2 flash update to 224.0.0.9 via dmz1 (10.0.2.120)   
RIP: build flash update entries - suppressing null update   
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.2.120)   
RIP: build update entries - suppressing null update

Now the authentication has been enabled but keys on 2 peers are not the same:

RIP: sending v2 update to 224.0.0.9 via inside (136.6.121.12)
RIP: build update entries   
10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0   
RIP: Update contains 4 routes   
RIP: Update queued   
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.0.120)   
RIP: build update entries   
136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.121.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0   
RIP: Update contains 4 routes   
RIP: Update queued   
RIP: Update sent via inside rip-len:92   
RIP: Update sent via dmz1 rip-len:92   
RIP: ignored v2 packet from 136.6.123.3 (invalid authentication)   
RIP: sending v2 update to 224.0.0.9 via inside (136.6.121.12)   
RIP: build update entries   
10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0   
RIP: Update contains 4 routes   
RIP: Update queued   
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.0.120)   
RIP: build update entries

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.