Why do we even need these technologies one might ask? The above technologies are useful for route filtering, which reduces the size of routing tables, saving memory, improves router performance, and makes the internetwork more secure by limiting the flow of packets. By using distribution lists, we can classify whether a route should be permitted to be sent or received (filtered). We can also specify the direction and optionally, the specific interface on which the filter updates.
Filtering using ACLs:
ACL must match a route with a permit clause for the route to be advertised, and match with a deny clause for the route to be filtered. To apply the filter, you use the distribution-list <acl#> <direction> <interface> command. If you were to have multiple sub-interfaces, then you would need to apply the distribution list to each and ever sub-interface. You could also apply the distribution-list <acl#> <direction> command, without specifying the particular interface. Not specifying the interface would cause it to implement the distribution-list on every interface.
Filtering using IP Prefix Lists:
IP Prefix lists can examine both the prefix and the prefix length, and a range of prefixes or a range of prefix lengths. To implement with prefix lists, you use the same distribute-list command, but referencing the created prefix list. The main advantage of using prefix lists over ACLs are that IP prefix lists allow matching of prefix length, where ACLs cannot. Also, the internal processing of the IP prefix lists uses an internal tree structure that results in faster matching of routes as compared to ACLs. IP prefix lists provide mechanisms to match two components of an IP route: The route prefix (subnet number) and prefix length (subnet mask). Like the permit or deny keywords just imply whether a route is matched (permit) or not (deny). Also unlike ACLs, IP prefix lengths examine the prefix length as well.
There are 4 prefix list parameters:
Neither: configured length must equal route-length
(Example: ip prefix-list fred deny 10.0.0.0/8 matches 10.0.0.0/8, but not 10.0.0.0/20)
Both ge and le: ge-value<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 le 22 matches 10.0.0.0/20, but not 10.0.0.0/23)
Only le: config-length<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 le 20 matches 10.0.0.0/19, but not 10.0.0.0/21)
Only ge: ge-value<=route-length<=32
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 matches 10.0.0.0/21, but not 10.0.0.0/18)
Filtering using Route Maps:
Route-maps, the third route filtering tool that can be referenced with the distribute-list command, provides programming logic with if/than/else like capabilities. Route maps can also be used to filter routes during the redistribution process, and to set BGP path attributes (PAs) for the purpose of influencing the choice of the best routes in an internetwork.
The syntax for setting up route maps are as follows:
route-map <route-map name> <deny/permit> <sequence#>
match <criteria> (The criteria field can be left blank, this would match all)set <action> (In the case with distribution lists, we would leave out the set parameter, as it is not needed to filter routes).
The match portion is where this can get a bit confusing...say you have the following scenario:
route-map sample-rm permit10
match ip access-list 2
access-list 2 deny 10.17.32.0 0.0.31.255
distribute-list route-map sample out
Should the particular route be permitted per the route-map, or denied per the access-list? In the case of route maps using access lists and prefix lists, if the access list is a deny, then the match statement is not fulfilled. Basically, by having a deny in the ACL or prefix list, the IOS then consider the next route-map command!
- Route-map commands with the permit option either cause a route to be allowed through (if matched by the match command) or remain in the list of routes to be examined by the next route-map clause.
- Route-map commands with the deny option either filter the route (if matched by the match command) or leave the route in the list of routes to be examined by the next route-map clause)
- If a clause's match command refer to an ACL or prefix list, and the ACL or prefix list matches a route map with the deny action, the route is not necessarily filtered. Instead, it just means that the route does not match that particular match command and can then be considered by the next route-map clause.
- The route-map command includes an implied deny all clause at the end; to configure a permit all use the route-map command, with a permit action, but without the match command.
Note: To match all packets, simply omit the match command from the route-map configuration.
No comments:
Post a Comment