01-14-2013 07:35 PM - edited 03-04-2019 06:42 PM
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
Solved! Go to Solution.
01-16-2013 02:50 AM
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:
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:
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
01-15-2013 12:00 AM
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.
01-15-2013 12:16 AM
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
01-15-2013 01:11 AM
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.
01-15-2013 02:24 AM
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
01-15-2013 03:56 AM
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 ***
01-15-2013 05:04 PM
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
01-15-2013 09:29 PM
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
01-16-2013 02:50 AM
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:
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:
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
01-16-2013 02:23 PM
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
01-16-2013 03:02 PM
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
01-18-2013 07:59 PM
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
01-18-2013 08:17 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide