blog
    Using Extended Access-Lis ...
    05 January 08

    Using Extended Access-Lists In A Distribute-List

    Posted byBrian McGahan
    facebooktwitterlinkedin
    news-featured

    Hi Brian,

    I'm trying to create a distribute-list in RIP to allow only even routes to be received. I can do it successfully with a standard ACL, however if I use an extended ACL I can't get any routes at all. I've heard that extended ACLs are better because they also check the netmask. What am I doing wrong?

    Using an extended access-list with a distribute-list is supported, however the syntax can be a little confusing because it means different things for different applications. When using an extended ACL for a distribute-list in BGP it acts like a prefix-list. This means that you can match on both the address of the prefix and the subnet mask. In other words if you have prefixes 10.0.0.0/8 and 10.0.0.0/16 you can distinguish between them by saying not only must the address be 10.0.0.0 but the subnet mask must be /8. In prefix-list syntax this is very straightforward, as to match this prefix we would use the following:

    ip prefix-list PREFIX1 permit 10.0.0.0/8
    

    When using an extended access-list in BGP the syntax of the list changes in that we are not matching source and destination pairs, but instead are matching the address and netmask. In extended ACL syntax the above prefix-list would read:

    access-list 100 permit ip host 10.0.0.0 host 255.0.0.0
    

    This means that the address must be exactly 10.0.0.0 and the subnet mask must be exactly 255.0.0.0. By changing the “host” keyword to a wildcard mask we can do fuzzy binary matches. For example the following syntax means check any address that starts with “192.168” and has a subnet mask of /24:

    access-list 101 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.0
    

    In other words this list matches 192.168.0.0/24, 192.168.100.0/24, 192.168.200.0/24, etc.

    This extended access-list syntax can also be used in a route-map for redistribution filtering in both IGP and BGP. For example if we took the previous access-list 101 and matched it in a route-map as follows:

    route-map OSPF_TO_RIP permit 10
    match ip address 100
    !
    router rip
    redistribute ospf 1 metric 1 route-map OSPF_TO_RIP

    This syntax would say that we want to redistribute OSPF routes into RIP, but only those which are 192.168.X.X/24.

    The confusion for this extended access-list implementation is that when it is called as a distribute-list in IGP the syntax changes. In the previous examples the normal “source” field in the ACL represents the network address, where the “destination” field represents the subnet mask. In IGP distribute-list application the “source” field in the ACL matches the update source of the route, and the “destination” field represents the network address. This implementation allows us to control which networks we are receiving, but more importantly who we are receiving them from. Take the following topology:

    R1, R2, and R3 share an Ethernet network 123.0.0.0/8 that is running RIP. Both R1 and R2 are advertising the identical prefixes 10.0.0.0/8 and 20.0.0.0/8 to R3. Their configurations are as follows:

    R1#show ip int brief | exclude unassigned
    

    Interface IP-Address OK? Method Status Protocol
    FastEthernet0/0 123.0.0.1 YES manual up up
    Loopback0 10.0.0.1 YES manual up up
    Loopback1 20.0.0.2 YES manual up up

    R1#show run | begin router rip
    router rip
    version 2
    network 10.0.0.0
    network 20.0.0.0
    network 123.0.0.0

    R2# show ip int brief | exclude unassigned

    Interface IP-Address OK? Method Status Protocol
    FastEthernet0/0 123.0.0.2 YES manual up up
    Loopback0 10.0.0.1 YES manual up up
    Loopback1 20.0.0.2 YES manual up up

    R2#sh run | begin router rip
    router rip
    version 2
    network 10.0.0.0
    network 20.0.0.0
    network 123.0.0.0

    R3#show ip route rip
    R 20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
    [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0
    R 10.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
    [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

    From this output we can see that R3 has the two prefixes installed twice, once from R1 and once from R2. Now let’s suppose that prefix 10.0.0.0/8 we only want to receive from R1, while prefix 20.0.0.0/8 we only want to receive from R2. We can accomplish this with an extended access-list as follows:

    R3#conf t
    Enter configuration commands, one per line. End with CNTL/Z.

    R3(config)#access-list 100 permit ip host 123.0.0.1 host 10.0.0.0
    R3(config)#access-list 100 permit ip host 123.0.0.2 host 20.0.0.0
    R3(config)#router rip
    R3(config-router)#distribute-list 100 in Ethernet0/0
    R3(config-router)#end
    R3#clear ip route *
    R3#show ip route rip
    R 20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
    R 10.0.0.0/8 [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

    We can see now R3 only has one entry for each prefix, with the 10.0.0.0/8 coming only from R1 and the 20.0.0.0/8 coming only from R2. The disadvantage of this application however is that we cannot distinguish prefixes based on their netmask. For example we could not say that we want to receive prefix 172.16.0.0/16 from only R1 and prefix 172.16.0.0/24 only from R2. For this implementation in IGP we would use a prefix-list that is called from a distribute-list with the “distribute-list prefix” syntax under the routing process.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo