Extended access-list used on outbound Distribute-list doesn't work in RIP

[yiwang0030]

Hi all,

I found out using extended access list on outbound distribute-list doesn't work as long as the source address in the access-list is not set to 'any'.

(2.2.2.2/24) Lo0 R2 F0/0(12.0.0.2/24) ----------- (12.0.0.1/24)F0/0 R1 F0/1(13.0.0.1/24) ----------------- (13.0.0.3/24) F0/0 R3

                                                                                             |

                                                                                             |

                                                                                 F0/2(14.0.0.1/24)

                                                                                             |

                                                                                             |

                                                                                             |

                                                                   (4.4.4.4/24) Lo0 R4 F0/0(14.0.0.4/24)

For example, all run rip v2, disable auto-summary,  without any filter on all routers, R3 will receive R2's loopback network 2.2.2.0/24 and R4's loopback network 4.4.4.0/24

I want R3 learn routes coming from R2 only, I performed a outbound distribute list on R1

Then I do the follonging on R1:

access-list 100 permit ip host 12.0.0.2 any

router rip

version 2

network 0.0.0.0

distribute-list 100 out FastEthernet0/1

no auto-summary

All routes will be filterd, R3 will not have any routes learned from rip in it's routing table.

The only way can makes R3 receive something, is change the source protion to 'any'

access-list 100 permit ip any any

But this will makes extended ack as a standard access list without any source filter.

However the inbound distribute list with extended access list works fine

Could any one explain why?

Thank you!

Yi

[cadet alain]

Hi,

I just labbed your topology and as you see on R3 the Loopback from R2 is like this:

R3(config-router)#do sh ip route 2.2.2.0 255.255.255.0

Routing entry for 2.2.2.0/24

  Known via "rip", distance 120, metric 2

  Redistributing via rip

  Last update from 13.0.0.1 on FastEthernet0/0, 00:00:20 ago

  Routing Descriptor Blocks:

  * 13.0.0.1, from 13.0.0.1, 00:00:20 ago, via FastEthernet0/0

      Route metric is 2, traffic share count is 1

So the source of the updates is not 12.0.0.2  and that's why you are filtering all RIP routes on R3 with your outbound distribute-list

Regards.

Alain

Don't forget to rate helpful posts.

[Karsten Iwen]

Hi Cadet and Yi,

have you also tested the changed source in the ACL? If I remember right it doesn't work for outgoing distribute-lists, only incoming if an extended ACL is used. And a quick look at the command-reference only shows the usage of standard ACLs.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[cadet alain]

Hi Karsten,

Yes you're right it won't work with outbound distribute-list( good catch  ) but I even wonder how the OP gets it working with a distribute-list applied inbound on R3 as the  update source is not 12.0.0.2.

Regards.

Alain

Don't forget to rate helpful posts.

[yiwang0030]

Hi Cadet,

Yes, I noticed the source on R3 is 13.0.0.1.

I also try using 13.0.0.1 as the source address instead of 12.0.0.2 in that extended access, same issue, R3 will not have any rip route installed.

Thanks for your reply!

Yi

[John Blakley]

I was able to get this to work with an outbound acl. Here's what I have:

R1 ---> R2 ----> R3

R1 has 1.1.1.1

R2 has 2.2.2.2

R3 has nothing special other than routes to 1.1.1.0 and 2.2.2.0.

Normally, you'd use a standard acl, but since the standard acl matches on the route from any source, on R2 I put an acl like:

access-list 101 permit ip host 0.0.0.0 host 1.1.1.0

Under RIP on R2:

router rip

distribute-list 101 out fa0/1 (toward R3)

R3's routing table shows:

Gateway of last resort is 192.168.23.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets

R       1.1.1.0 [120/2] via 192.168.23.2, 00:00:12, FastEthernet0/0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, Loopback1

C    192.168.23.0/24 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 192.168.23.2

ACL on R2 shows:

R2(config-router)#do sh access-list 101

Extended IP access list 101

    10 permit ip host 0.0.0.0 host 1.1.1.0 (12 matches)

R2(config-router)#

HTH,
John

*** Please rate all useful posts ***

[yiwang0030]

Hi John,

Thanks for your reply.

access-list 101 permit ip host 0.0.0.0 host 1.1.1.0 only filter destinations which make no difference with a standard access-list.

I believe it has same effect with my:  access-list 101 permit ip any host any, just simply change the second any to 1.1.1.0

Regards,

Yi

[XIE YAO]

1. Distribution-list seems only working in IN direction.

2. in my lab, I used below command on R3 and it's working.

Before:

R       2.2.2.0 [120/2] via 13.0.0.1, 00:00:14, Ethernet0/0

     3.0.0.0/24 is subnetted, 1 subnets

C       3.3.3.0 is directly connected, Loopback0

     13.0.0.0/24 is subnetted, 1 subnets

C       13.0.0.0 is directly connected, Ethernet0/0

     2.0.0.0/24 is subnetted, 1 subnets
R       2.2.2.0 [120/2] via 13.0.0.1, 00:00:11, Ethernet0/0
     3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, Loopback0
     4.0.0.0/24 is subnetted, 1 subnets
R       4.4.4.0 [120/2] via 13.0.0.1, 00:00:11, Ethernet0/0
     12.0.0.0/24 is subnetted, 1 subnets
R       12.0.0.0 [120/1] via 13.0.0.1, 00:00:11, Ethernet0/0
     13.0.0.0/24 is subnetted, 1 subnets
C       13.0.0.0 is directly connected, Ethernet0/0
     14.0.0.0/24 is subnetted, 1 subnets
R       14.0.0.0 [120/1] via 13.0.0.1, 00:00:11, Ethernet0/0

Change:

router rip

distribute-list 102 in Ethernet0/0

access-list 102 permit ip host 13.0.0.1 2.2.2.0 0.0.0.255

R3(config-router)# do clear ip route *

     2.0.0.0/24 is subnetted, 1 subnets

R       2.2.2.0 [120/2] via 13.0.0.1, 00:00:14, Ethernet0/0

     3.0.0.0/24 is subnetted, 1 subnets

C       3.3.3.0 is directly connected, Loopback0

     13.0.0.0/24 is subnetted, 1 subnets

C       13.0.0.0 is directly connected, Ethernet0/0

More detailed you can refer to this link, http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-a-distribute-list/ .

Hope this helps.

Yaoxie

[Peter Paluch · Accepted solution]

Dear friends,

My two cents on this issue.

Using ACLs in distribute-lists is, in my opinion, an unfortunate thing to do. Prefix lists are the way to go here. ACLs have originally been created as means to filter packet flows based on packet headers. Imagine the ACL as a software function that accepts certain input arguments - source IP, destination IP, L4 protocol number, L4 ports if applicable, etc. - and returns two possible values - permit or deny, based on entries inside the ACL. This design of ACLs conforms nicely to filtering packets. However, in distribute lists, you are not filtering packets but rather contents of routing protocol updates. Now, the contents of routing protocol updates are networks, netmasks, optionally next hop addresses - not exactly the types of input arguments an ACL expects to receive. How do you organize this information so that it can be an input for the ACL? You simply have to present some of these contents as "source IP", some other contents as "destination IP" to the ACL, and some other contents can not be input to an ACL at all because they do not resemble anything a generic ACL can process.

This makes the use of ACLs in distribute lists partially possible but at the same time, strongly unintuitive and hence not recommended.

I have found the log option to be very helpful in understanding what input arguments are passed to an ACL when used in a distribute list. Consider the following topology running RIPv2:

10.0.1.0/24 --- R1 --- 10.0.12.0/24 --- R2 --- 10.0.2.0/24

On R1, I have ACL 100 defined as follows:

access-list 100 permit ip any any log

Now, when used on R1 as distribute-list 100 out, the logging messages say:

*Mar  1 00:17:03.811: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 0.0.0.0 -> 10.0.1.0, 1 packet

Note the fields and their meaning for an ACL in the outbound direction:

• "0" is the L4 protocol as seen by the ACL. This input value wil always be set to 0 in distribute-list applications
• "0.0.0.0" is the "source IP" as seen by the ACL. This input value will always be set to 0.0.0.0 in distribute-list application, regardless of the value of the next-hop field in RIPv2 messages. In particular, it is not set to the route source or next hop.
• "10.0.1.0" is the "destination IP" as seen by the ACL. This input value will be set to the network address in the routing update

In other words, when filtering the routing updates in the out direction, you can filter advertised networks based only on their addresses. You can not filter based on network masks, route sources or next hops. In addition, for an extended ACL, the network address to be permitted/denied must be specified as the "destination IP", and the "source IP" will always be set to 0.0.0.0.

When using the same ACL 100 on R1 as distribute-list 100 in, the logging messages are:

*Mar  1 00:32:53.883: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 10.0.12.2 -> 10.0.2.0, 1 packet 

The meaning of input arguments to ACL in an inbound direction is as follows:

• "0" is the L4 protocol as seen by the ACL, and will always be set to 0.
• "10.0.12.2" is the "source IP" as seen by the ACL. This input value will be set to the next hop address of the received route. Not that this may either be the source address of the neighboring router if the next-hop field in the RIPv2 message is 0.0.0.0, or it may be the value of the next-hop field in the RIPv2 message if it is non-zero. In both cases, this "source IP" represents the next hop towards the route. Note, however, that this information is valid only for RIPv2. I've tested the EIGRP, and in EIGRP, the "source IP" is always set to the router advertising the route and not to the next-hop address. Confusing? Yeah, I think so.
• "10.0.2.0" is the "destination IP" as seen by the ACL. This input value will be set to the network address of the received route.

In other words, when filtering the routing updates in the in direction, you can filter received networks based on their addresses and next hops, with the next hop being the "source IP" and network address being the "destination IP" to the ACL. Again, you can not match on the subnet masks here which may be quite a strong limitation.

So in fact, using ACLs, especially extended ACLs in distribute-lists is basically forcing them into an application in which they "don't feel comfortable". Lots of confusion can arise from that. And I haven't started talking about using ACLs in BGP yet - that's again a different story!

Using the prefix lists is absolutely recommended, as they allow to match both for network addresses and netmasks without ambiguousities. If ACLs need to be used in distribute-lists, use standard ACLs only.

Best regards,

Peter

[yiwang0030]

Hi Peter

Thanks for your reply, thats what I'm looking for.

Regarding to

"10.0.12.2" is the "source IP" as seen by the ACL. This input value will  be set to the next hop address of the received route. Not that this may  either be the source address of the neighboring router if the next-hop  field in the RIPv2 message is 0.0.0.0, or it may be the value of the  next-hop field in the RIPv2 message if it is non-zero. In both cases,  this "source IP" represents the next hop towards the route. Note,  however, that this information is valid only for RIPv2. I've tested the  EIGRP, and in EIGRP, the "source IP" is always set to the router  advertising the route and not to the next-hop address. Confusing? Yeah, I  think so.

In which situation can RIP and EIGRP advise next hop different from advertising router? I thought both of them are distance vector protocal, routers are all directly adjacent, and they can only reach destination through the direct neighbor which advertise the route to them.

Thanks!

Regards,

Yi

[Peter Paluch]

Hello Yi,

Both RIPv2 and EIGRP carry an extra field in their updates that contains the recommended next hop for a particular route. This field can be populated in certain circumstances. For example, consider three routers on the same network. Routers A and B speak RIPv2 while B and C speak, say, OSPF. Router B speaks both protocols and performs the redistribution between RIPv2 and OSPF so that router A can reach networks behind router C. Under normal circumstances, router A would learn all networks via RIPv2 from B and use B as the next hop towards these networks. However, because all three routers are on the same segment, this would cause suboptimal routing - A would send data to B and B would send them out the same interface to C, despite the fact that A can send data to C directly.

This is where the recommended next hop field comes handy. When B redistributes routes learned via OSPF from C, it populates the recommended next hop field using the address of router C as the recommended next hop address. This way, router A can learn about these networks from B and yet use router C directly as the next hop towards them.

Another possibility of seeing the next hop is in DMVPN (Dynamic Multipoint VPN) networks. Here, individual edge routers form a VPN that connects them on a virtual basis to a single common network segment, and they have the ability to dynamically establish a tunnel between any two edge routers in this DMVPN, thereby emulating the capability of any two nodes on a common segment to talk to each other directly. However, in the DMVPN, adjacencies in routing protocols are only of the hub-and-spoke form, i.e. one of the routers is a hub router, the others are just spokes, and all spokes communicate within the routing protocol only with the hub, never on a spoke-to-spoke basis. Here, again, if a spoke learns about other networks from the hub router, it will normally use the hub as the next hop towards them. However, because in DMVPN, a spoke can talk to each other spoke directly, sending data through the hub would be like taking a huge detour. The recommended next hop field comes handy here, too: a hub learns about routes behind all spokes thanks to the routing protocol, and sends the list  of these networks to each hub, but for each network, it maintains the address of the spoke behind which the network is located as the recommended next hop address. Thanks to this, spoke routers know about other spokes and networks behind them, and can route data between each other directly.

Best regards,

Peter

[yiwang0030]

Hi Peter,

One more question.

There are few arguments (bgp, connected, eigrp, ospf, rip, static) are missing between inbound and outbound .

R7(config-router)#distribute-list 101 out ?

  Async              Async interface

  BVI                Bridge-Group Virtual Interface

  CDMA-Ix            CDMA Ix interface

  CTunnel            CTunnel interface

  Dialer             Dialer interface

  FastEthernet       FastEthernet IEEE 802.3

  Lex                Lex interface

  Loopback           Loopback interface

  MFR                Multilink Frame Relay bundle interface

  Multilink          Multilink-group interface

  Null               Null interface

  Port-channel       Ethernet Channel of interfaces

  Tunnel             Tunnel interface

  Vif                PGM Multicast Host interface

  Virtual-PPP        Virtual PPP interface

  Virtual-Template   Virtual Template interface

  Virtual-TokenRing  Virtual TokenRing

  bgp                Border Gateway Protocol (BGP)

  connected          Connected

  eigrp              Enhanced Interior Gateway Routing Protocol (EIGRP)

  ospf               Open Shortest Path First (OSPF)

  rip                Routing Information Protocol (RIP)

  static             Static routes

R7(config-router)#distribute-list 101 in ?

  Async              Async interface

  BVI                Bridge-Group Virtual Interface

  CDMA-Ix            CDMA Ix interface

  CTunnel            CTunnel interface

  Dialer             Dialer interface

  FastEthernet       FastEthernet IEEE 802.3

  Lex                Lex interface

  Loopback           Loopback interface

  MFR                Multilink Frame Relay bundle interface

  Multilink          Multilink-group interface

  Null               Null interface

  Port-channel       Ethernet Channel of interfaces

  Tunnel             Tunnel interface

  Vif                PGM Multicast Host interface

  Virtual-PPP        Virtual PPP interface

  Virtual-Template   Virtual Template interface

  Virtual-TokenRing  Virtual TokenRing

I believe these arguments (bgp, connected, eigrp, ospf, rip, static) are used to filter routes druing redistribute, but why it doesn't allow to filter in inbound direction?

Thank you!

Yi

[Peter Paluch]

Hello Yi,

I believe these arguments (bgp, connected, eigrp, ospf, rip, static) are  used to filter routes druing redistribute, but why it doesn't allow to  filter in inbound direction?

My understanding is that in the inbound direction, you have no way of knowing where does a particular route in a routing update come from. Some protocols do not even distinguish between internal and external (redistributed) networks, such as RIP, so you don't even know that this or that route has been redistributed. Other protocols like OSPF or EIGRP can distinguish between internal and redistributed networks but only EIGRP is actually carrying the information about where the route was redistributed from in its updates. Because there is no generally available support to identify the origin of an external network in a routing update across routing protocols, there is no support for filtering inbound updates based on the origin of the route.

Best regards,

Peter