Route filtering with a distribution list

[JonasV]

Hello Community

Normally I'm using a prefix-list in combination with route-map to filter prefix advertisements when configuring BGP.

For fun and to expand my knowledge, I was looking into the docs article about 'Route filtering with a distribution list'.
Link: http://docs.fortinet.com/document/fortigate/7.2.7/administration-guide/170065/route-filtering-with-a...

In my lab I have 3 FortiGates, running v7.2.7.

FGT1, FGT2 and FGT3.

FGT2 and FGT3 have eBGP peering established with FGT1.

FGT1 receives prefixes from both FGT2 and FGT3 and advertises everything. FGT1 also advertises a local originating prefix.

For testing, I would like to try and use the distribution list on FGT1 towards FGT3. I would like to filter out only the prefix received from FGT2. The local prefix that FGT1 advertises, still needs to go to FGT3.

However I can't seem to get it to work.

My ACL matches the prefix from FGT2 with exact-match enabled and action set to deny.

If I set the ACL on the outbound distribution list towards FGT3, then no prefix at all is received.

Anyone using this in production that can share some more insight to the usage?

[Toshi_Esumi · Accepted solution]

I was curios just like you because I never used "config router access-list". So I tested it myself. And, looks like the document you referred to seems to have an error/missing part. In the ACL, until I added "permit the rest" below, it would deny everything with implicit deny at the end of ACL. After I configured like below, it denied 172.31.255.254/32 but allowed everything else.

config router access-list
  edit "testACL1"
    config rule
      edit 1
        set action deny
        set prefix 172.31.255.254 255.255.255.255    <-- I used a loopback with a /32 IP
        set exact-match enable
      next
      edit 2
        set prefix any
      next
    end
  next
end

I wouldn't use access-list unless I need to use Cisco-style wildcard like:

 set wildcard 172.0.255.254 0.31.0.0

I don't think this can be done with prefix-list.

Toshi

[sahmed_FTNT]

Hello, for configuration purposes you can use the below link for reference:

FortiGate BGP configuration to announce specific routes and accept only a default route (prefix list...: https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-BGP-configuration-to-announce-sp...

[Toshi_Esumi · Accepted solution]

I was curios just like you because I never used "config router access-list". So I tested it myself. And, looks like the document you referred to seems to have an error/missing part. In the ACL, until I added "permit the rest" below, it would deny everything with implicit deny at the end of ACL. After I configured like below, it denied 172.31.255.254/32 but allowed everything else.

config router access-list
  edit "testACL1"
    config rule
      edit 1
        set action deny
        set prefix 172.31.255.254 255.255.255.255    <-- I used a loopback with a /32 IP
        set exact-match enable
      next
      edit 2
        set prefix any
      next
    end
  next
end

I wouldn't use access-list unless I need to use Cisco-style wildcard like:

 set wildcard 172.0.255.254 0.31.0.0

I don't think this can be done with prefix-list.

Toshi

[Toshi_Esumi · Accepted solution]

By the way, this implicit deny behavior is consistent with Cisco's ACL. I remember when I locked up all customer traffic since I didn't put "permy ip any any" at the end on a Cisco router very long time ago. But cisco's case, all you need to do is to reboot the router unless you save the config already.

[JonasV]

Hi @Toshi_Esumi 

Great finding! 
I can relate this to prefix-lists also.
If for example I create a prefix-list, where the only rule entry is a ‘deny’ statement for a single prefix, then nothing gets through either, because of a ‘hidden’ implicit deny logic also.

I don’t think I would ever use this in production, as mentioned - I usually use prefix-list and route maps. 

[Toshi_Esumi]

When you use it with a route-map the prefix-list or access-list can be used to just match specific prefixes and its action is decided at the route-map side. In that case, you don't have to allow the rest at the prefix-list side. You can add that part on the route-map side.

Since the route-map add one more layer on top of the prefix-list or access-list, it's more flexible to control the filtering behaviours including combining both prefix-lists and access-lists in one route-map.

Toshi