3 Replies Latest reply: Mar 4, 2019 8:20 AM by Steven Davidson RSS

    route-maps don't have an implicit deny?

    Crisco

      I did a lot of searches and found many people referencing route-maps having an implicit deny at the end, just like ACLs. For all my 20 years of network engineering I also thought this was the case. However based on behavior I've recently seen, and based on Cisco's documentation, I believe this is a common fallacy.

       

      See: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/49111-route-map-bestp.html

      "Each ACL ends with an implicit deny statement, by design convention; there is no similar convention for route-maps. If the end of a route-map is reached during matching attempts, the result depends on the specific application of the route-map."

       

      Yes the behavior when using route-maps is often as if it had a deny at the end - for example when used as a route filter, anything not matching a permit will get dropped. But, if there was an implicit deny, wouldn't the following drop all prefixes except 5.5.5.5/32?

       

      route-map TEST permit 10

        continue

        set community 1:1

      route-map TEST permit 20

         match <prefix-list that only 5.5.5.5/32 matches>

       

      router bgp 1

        neighbor 1.2.3.4 remote-as 5

        neighbor 1.2.3.4 route-map TEST out

       

      You might think "the first clause you have has no match statement, and therefore permits all routes". And you're not wrong. But the "continue" says don't stop at this clause and keep going. If there was truly an implicit deny at the end, that should deny all prefixes except 5.5.5.5/32. But instead ALL routes are allowed through. If, however, you add an EXPLICIT deny to the end (with nothing in the clause):

       

      route-map TEST deny 30

       

      ...it WILL drop all routes except 5.5.5.5/32.

       

      I tested this in the lab to confirm this behavior. So does anyone dispute that route-maps do NOT have an implicit deny?

        • 1. Re: route-maps don't have an implicit deny?
          Steven Davidson

          I can already kind of see the direction where this is heading but I'll bite.  The implicit deny is that if there's no explicit match by the time it finishes the final stanza then nothing was matched and the route-map is not used (ie the route-map resulted in no set operations).  In the case you demonstrate seq 10 matches but then further sequences must also be evaluated and when they reach "deny 30" the permit is overridden with an explicit deny.  The absence of "deny 30" means that the "permit 10", which permitted all prefixes, survives as if it were the final sequence at the end of the line.  Using "continue" is making it an apples to oranges comparison.  If no matches are made by the time it reaches the end then nothing matches and no set actions are taken (effectively implicitly denying all actions).  But in your case, with the absence of "deny 30" a match was made in "permit 10" so it didn't hit the end without a match.  If there isn't an implicit deny at the end of a route-map then what is the other alternative?  An implicit permit?  An implicit 'meh'?  Is there an implicit permit?  If nothing matches does everything match?  No.  If there isn't an implicit permit then logic would say that there's an implicit deny.  Just my 2 cents.

          • 2. Re: route-maps don't have an implicit deny?
            Crisco

            Thanks for your reply.

            If there isn't an implicit deny at the end of a route-map then what is the other alternative?

            I would suggest there doesn't need to be an implicit anything, and it seems like there isn't. As the documentation I linked says: "If the end of a route-map is reached during matching attempts, the result depends on the specific application of the route-map." (On a related note, maybe in reality ACLs are exactly the same and the "implicit deny" is handled by the specific application of the ACL, and not some general ACL processing subroutine in the code that always adds the deny automatically, but that's a different topic).


            If there was an implicit deny, wouldn't it act the same as an explicit deny? Yes, a permit already matched, and processing continues because of the "continue", but why would an implicit statement not count the same as an explicit statement? Doesn't "implicit" just mean "invisible but known to be there", not "optional"?

             

            Using "continue" is making it an apples to oranges comparison.

            I agree that it changes things - with the "continue" the route-map behaves unlike an ACL or a normal route-map - where once a line matches, the router is done evaluating.

             

            Maybe it's just semantics, and maybe we won't know the true answer unless an actual developer chimes in (which seems unlikely), but it seems like the behavior when using "continue" on a permit clause that matches (or has no match statement), is one of these two things:

            1. There is no implicit deny at the end. The result of hitting the end depends on the application of the route-map and is handled by the code using it.
            2. The implicit deny only applies IF there was no previous matching permit

             

            I would argue that option 1 makes more sense - implicit just means you don't see the deny, but it's there. And if it's there, it should act the same as an explicit deny. Obviously option 2 is a possibility as well. I would like to know the real answer even if it seems like a minor point, since the behavior is the same and it's easier to just think of there being an implicit deny and treat the corner case of "continue" specially (especially since "continue" is probably not that widely used).

            • 3. Re: route-maps don't have an implicit deny?
              Steven Davidson

              Crisco wrote:

               

               

              If there was an implicit deny, wouldn't it act the same as an explicit deny? Yes, a permit already matched, and processing continues because of the "continue", but why would an implicit statement not count the same as an explicit statement? Doesn't "implicit" just mean "invisible but known to be there", not "optional"?

               

              Think about the normal operation of a route-map (like an ACL, stop at the first match and process no futher) and then think about the whole reason why the 'continue' option exists to begin with.  By using 'continue' you are saying "OK, I EXPLICITLY matched something BUT I want the option of overriding the explicit condition".  In my opinion, overriding an explicit match should also require another explicit match.   If it were me coding this I would keep track that an explicit match was made (and the subsequent result of that match - the set), continue on, and if no other explicit match is subsequently made then I would march ahead with the set condition of the original match (like I would if the continue never existed) and call it a day.