Wednesday, April 25, 2007
Modifying an ACL (Problem #77)
Consider the following ACL as displayed by the show command
The configuration looks like this
It turns out that a new ACL entry needs to be added. The entry is
and needs to be added as the second entry in ACL 101 shown above.
What is the most efficient way of adding this entry to the ACL?
R1#show access-lists
Extended IP access list 101
1 permit ip host 10.1.1.1 host 11.1.1.1
2 permit ip host 12.1.1.1 host 13.1.1.1
3 deny tcp host 14.1.1.1 host 15.1.1.1 eq www
4 permit ip host 14.1.1.1 host 15.1.1.1
5 deny tcp host 16.1.1.1 host 17.1.1.1 eq www
6 permit ip host 16.1.1.1 host 17.1.1.1
R1#
The configuration looks like this
access-list 101 permit ip host 10.1.1.1 host 11.1.1.1
access-list 101 permit ip host 12.1.1.1 host 13.1.1.1
access-list 101 deny tcp host 14.1.1.1 host 15.1.1.1 eq www
access-list 101 permit ip host 14.1.1.1 host 15.1.1.1
access-list 101 deny tcp host 16.1.1.1 host 17.1.1.1 eq www
access-list 101 permit ip host 16.1.1.1 host 17.1.1.1
It turns out that a new ACL entry needs to be added. The entry is
access-list 101 deny tcp host 12.1.1.1 host 13.1.1.1 eq www
and needs to be added as the second entry in ACL 101 shown above.
What is the most efficient way of adding this entry to the ACL?
Friday, September 01, 2006
Some Thoughts on Policy Based Routing (PBR)
When I first encountered PBR, I understood it mainly as source-based routing as opposed to the usual destination-based routing. The usual forwarding process on routers conceptually does a look-up in the routing table for the destination address in the packet and uses the next-hop information it gets from the routing table to pass the packet onwards towards its destination. The routing table itself is primed by information exchanged by routing protocols or via static routes. (In fact, it is useful to think of even static routes and connected routes themselves as special cases of routing protocols.)
However with PBR, this process is changed because the source address of the packet can affect the handling of the packet. In effect, with the usual packet forwarding scheme all variables other than the destination address of the packet are dont-cares while with PBR those other variables stop being dont-cares. So for instance, PBR would allow a router to forward all packets with the destination address D to be forwarded via interface serial0 except when those packets were some specific source address S in which case the packets would be forwarded to interface serial1. Thus, the forwarding process becomes sensitive to the source address.
Actually, thinking of PBR as mainly source-based or source-sensitive routing is limiting because using PBR one could also make it sensitive to a number of other variables like the length of the packet, any layer4 information in the packet, whether the packet is of a particular protocol type etc. The way these variables are selected and caused to affect the forwarding process is done via route maps.
In some recent reading I realized that there was another way to look at PBR. As with all things, multiple ways of looking at something results in a better understanding of the concept at hand. The other way to look at PBR is to think of it as a powerful static route -- static routes on steroids. Just as static routes define how packets destined prefixes will be handled, PBR specified how packets that match certain criteria will be handled. It is just that the criteria include destination addresses as with static routes but also include much more. Also, just as a static route by virtue of its low administrative distance will override any routes that may be learnt for the same prefix via some routing protocol, PBR specified policies will override what the routing table lookup might have specified for that destination prefix. This way of looking at PBR allows one to understand PBR as a generalization of the idea of static routes.
The generalized nature of PBR causes some representational difficulties w.r.t displaying the semantics of PBR configuration. The effect of a static route is clearly discernible just by looking at the routing table via the "show ip route" command. However, it is not possible to see the effect of PBR simply by looking at the routing table. The very general nature of PBR causes it to be a bit difficult to capture the effect of the PBR configuration on a running system simply by some output from a show command. To see how the PBR configuration would affect the traffic flow, one needs to mentally parse the configured route maps and see which interfaces the policy routing is applied to and then think of the effect on the traffic flow depending on variables like source and destination addresses, source and destination ports, packet lengeth etc in the packet stream. The fact that the multi-variate nature of what PBR deals with makes it hard to display the effect of PBR via show command output is akin to the difficulty of representing and visualizing n-dimensional space for values of n greater than 3.
However with PBR, this process is changed because the source address of the packet can affect the handling of the packet. In effect, with the usual packet forwarding scheme all variables other than the destination address of the packet are dont-cares while with PBR those other variables stop being dont-cares. So for instance, PBR would allow a router to forward all packets with the destination address D to be forwarded via interface serial0 except when those packets were some specific source address S in which case the packets would be forwarded to interface serial1. Thus, the forwarding process becomes sensitive to the source address.
Actually, thinking of PBR as mainly source-based or source-sensitive routing is limiting because using PBR one could also make it sensitive to a number of other variables like the length of the packet, any layer4 information in the packet, whether the packet is of a particular protocol type etc. The way these variables are selected and caused to affect the forwarding process is done via route maps.
In some recent reading I realized that there was another way to look at PBR. As with all things, multiple ways of looking at something results in a better understanding of the concept at hand. The other way to look at PBR is to think of it as a powerful static route -- static routes on steroids. Just as static routes define how packets destined prefixes will be handled, PBR specified how packets that match certain criteria will be handled. It is just that the criteria include destination addresses as with static routes but also include much more. Also, just as a static route by virtue of its low administrative distance will override any routes that may be learnt for the same prefix via some routing protocol, PBR specified policies will override what the routing table lookup might have specified for that destination prefix. This way of looking at PBR allows one to understand PBR as a generalization of the idea of static routes.
The generalized nature of PBR causes some representational difficulties w.r.t displaying the semantics of PBR configuration. The effect of a static route is clearly discernible just by looking at the routing table via the "show ip route" command. However, it is not possible to see the effect of PBR simply by looking at the routing table. The very general nature of PBR causes it to be a bit difficult to capture the effect of the PBR configuration on a running system simply by some output from a show command. To see how the PBR configuration would affect the traffic flow, one needs to mentally parse the configured route maps and see which interfaces the policy routing is applied to and then think of the effect on the traffic flow depending on variables like source and destination addresses, source and destination ports, packet lengeth etc in the packet stream. The fact that the multi-variate nature of what PBR deals with makes it hard to display the effect of PBR via show command output is akin to the difficulty of representing and visualizing n-dimensional space for values of n greater than 3.
Friday, August 25, 2006
Back after a break from blogging.
I have been away for a while from my blog because of some changes at work that left me with increased responsibilities. I have gotten used to the changes at work and am now raring to get back to the world of CCIE and CCNP. And to be honest, I had just gotten a bit fast and lazy after finishing the CCNP! (Note to self: Try not to do that in future.)
The next milestone in my path is to finish the CCIE Routing and Switching written exam. I don't even want to think about the CCIE lab exam until the written exam is done. As far as I can see, the written exam is based on the the sum of all the material for the CCNP exams with the exception that for some strange reason Cisco has thought fit to add wireless topics to the exam too. The lab does not include wireless and so that topic seems a little out of place in that mix for the written exam, but I guess I will have to read up on that. I am not very knowledgeable with wireless but I will have to fix that soon. However, for all the other stuff it seems that it will suffice to simply brush up all the CCNP topics and go handle the CCIE written exam.
In any case, I am back and will hopefully update this more often and again get to interact with and learn from all the great readers of this blog. It will be good to hear from you all again!
The next milestone in my path is to finish the CCIE Routing and Switching written exam. I don't even want to think about the CCIE lab exam until the written exam is done. As far as I can see, the written exam is based on the the sum of all the material for the CCNP exams with the exception that for some strange reason Cisco has thought fit to add wireless topics to the exam too. The lab does not include wireless and so that topic seems a little out of place in that mix for the written exam, but I guess I will have to read up on that. I am not very knowledgeable with wireless but I will have to fix that soon. However, for all the other stuff it seems that it will suffice to simply brush up all the CCNP topics and go handle the CCIE written exam.
In any case, I am back and will hopefully update this more often and again get to interact with and learn from all the great readers of this blog. It will be good to hear from you all again!
