PrefixList, RouteMap Advertisements Issue

[tryllz]

Hi,

I'm facing an issue where the Prefix List I have set for BGP is only advertising 1 route from each Prefix list, I have 2 Prefix List with 2 routes in each list, and each list is added to a Route Map. I'm sure I'm not configuring as it should be, just not able to figure out what is it.

I have setup my Prefix List as follows



And RouteMaps are configured as follows





The Fortigate firewall routes from OPNSense received are as below, routes not being advertised are 10.21.30.0, and 10.21.45.0.

Code: [Select]

Routing table for VRF=0
B*      0.0.0.0/0 [20/0] via 192.168.9.11 (recursive is directly connected, port1), 02:15:57, [1/0]
B       10.21.35.0/24 [20/1] via 192.168.9.25 (recursive is directly connected, port1), 00:02:44, [1/0]
B       10.21.40.0/24 [20/1] via 192.168.10.25 (recursive is directly connected, port2), 00:02:44, [1/0]
B       192.168.1.0/24 [20/0] via 192.168.9.11 (recursive is directly connected, port1), 02:15:57, [1/0]

OPNSense receives all routes as configured in the Fortigate



Not able to figure out what is misconfigured ?

I thought it was a sequence number issue so I changed all numbers in both Prefix list and Route Map, that did not help.

Thank You

[Seimus]

For redistribution BGP + Prefix list works in following way.

Deny or Permit statement in a RouteMap states if a prefix will be advertised
Deny or Permit statement in a Prefix-list states if a prefix will be evaluated by specific entry in the prefix list (its doesn't do any real permitting or denying)

In order for BGP to advertise a prefix to his peer, a prefix needs to match a specific Prefix list with a Permit RouteMap entry. Addition to this BGP will only advertise prefixes to his peers that are installed in the routing table. If you have a RouteMap + Prefix list allowing such prefix to be advertise but that prefix is not in the routing table, BGP will not advertise it all.

So question for you, those prefixes you are not seeing on the Peer device, does have them OPNsense in its routing table?

Regards,
S.

[tryllz]

Thanks,

I have checked, the routes not advertising are in the routing table in OPNSense.

I created a new setup in VMware workstation, and it had the same behaviour, once a RouteMap is added with 2 or more prefix list 1 route in Fortigate.

[Seimus]

When you put only 1 prefix list, let say that one that the prefix is not advertised. Will it start to work then?

Remove all the prefix list from the RP and put in only one the one that is not currently working - check if you see it on the Peer being received.

Also the Seq is only locally significant per the same RP or PL. You basically state in which order multiple entries in a RP or PL should be evaluated.

Regards,
S.

[tryllz]

VMware workstation Setup.

With No RouteMap added to neighbours all routes are advertised.

Code: [Select]

Routing table for VRF=0
B       10.10.11.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:00, [1/0]
B       10.10.12.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:00, [1/0]
B       10.10.13.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:00, [1/0]
C       192.168.3.0/24 is directly connected, port1
B       192.168.30.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:00, [1/0]
B       192.168.35.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:00, [1/0]
C       192.168.40.0/24 is directly connected, port2
C       192.168.50.0/24 is directly connected, port3

With 1 Prefix-List which has only 1 network (10.10.11.0/24) in it, advertises fine.

Code: [Select]

Routing table for VRF=0
B       10.10.11.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:15, [1/0]
C       192.168.3.0/24 is directly connected, port1
C       192.168.40.0/24 is directly connected, port2
C       192.168.50.0/24 is directly connected, port3

With 1 Prefix-List with 2 networks in it (10.10.11.0/24, 192.168.35.0/24), only 1 network is advertised.

Code: [Select]

Routing table for VRF=0
C       192.168.3.0/24 is directly connected, port1
B       192.168.35.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:20, [1/0]
C       192.168.40.0/24 is directly connected, port2
C       192.168.50.0/24 is directly connected, port3




I have rearranged the networks in the prefix-list, it has no significance which is added 1st only 192.168.35.0/24 get advertised.

[tryllz]

Seems like some issue between Prefix-Lists and RouteMaps..

Found this to work [https://forum.opnsense.org/index.php?topic=28414.0]

If all permitted and denied routes are named the same Prefix-List then added as a prefix-List in Outbound, it works as expected..

As can be seen below, I have all 3 prefix-lists all with same name p1, which are then added to the neighbours as below..





In the prefix-list I have permitted 192.168.30.0/24 and 10.10.11.0/24, and denied 10.10.12.0/24.

The rouring table in Fortigate shows permitted networks only.

Code: [Select]

Routing table for VRF=0
B       10.10.11.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:01:52, [1/0]
C       192.168.3.0/24 is directly connected, port1
B       192.168.30.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:01:52, [1/0]
C       192.168.40.0/24 is directly connected, port2
C       192.168.50.0/24 is directly connected, port3

[Seimus]

In that new P1 PL you have a prefix entry per line. Totally 3 prefixes in one and same PL. If you take this PL in this exact format and put it into RP still same issue observed?

If yes it could be a BUG, would be worth to report it on the FRR Git repo.

Overall,
When you compose a PL, you put the prefixes per entry/line. PL similar to ACL has an explicit deny at the end so what is not permitted will not be evaluated within the specific RP. AS a RP has as well an explicit deny, such a prefix will be not advertised at all.

PL example:
ip prefix-list PL1 seq 10 permit  X.X.Y.X/XX
ip prefix-list PL1 seq 11 permit  X.X.Z.X/XX
ip prefix-list PL1 seq 12 permit  X.X.W.X/XX

Above is only one PL with multiples entries evaluated from the lowest seq number 1st

RP example:

route-map RP-out permit 10
 match ip address prefix-list PL1

RP example witch multiple PLs:

route-map RP-PL1orPL2-out permit 10
 match ip address prefix-list PL1
 match ip address prefix-list PL2


Prefix match PL1 OR PL2.

Attaching to BGP:

neighbor x.x.x.x route-map RP-out out

or

neighbor x.x.x.x route-map RP-PL1orPL2-out out

When you do several PLs into one RP, this should work too, but if you have multiple PL in one RP statement, there is an OR operator between the PLs.

Regards,
S.

[tryllz]

In that new P1 PL you have a prefix entry per line. Totally 3 prefixes in one and same PL. If you take this PL in this exact format and put it into RP still same issue observed?

I have tested this 2 ways

1) adding all the 3 P1 PL into the RouteMap
2) adding only 1 of the 3 P1 PL into the RouteMap

Both ways it works as expected, only shows routes permitted in the PL.

Code: [Select]

Routing table for VRF=0
B       10.10.11.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:05, [1/0]
C       192.168.3.0/24 is directly connected, port1
B       192.168.30.0/24 [20/1] via 192.168.3.151 (recursive is directly connected, port1), 00:00:05, [1/0]
C       192.168.40.0/24 is directly connected, port2
C       192.168.50.0/24 is directly connected, port3

[Seimus]

So it looks like that FRR currently doesn't support multiple PL in one RP. Most likely they didn't implement the OR in cause you use several PLs in one RP entry.

As mentioned this should be possible, on Juniper as well CISCO this method is doable.

However from implementation perspective, usually you don't do multiple PLs in one RP entry. Cause all you need is 1 PL (with several entries) in RP per entry.

For you you can in this case just do as advised,
1. Create a PL and specify prefix per entry seq
2. Allow only prefixes you want to advertise
3. Attach only 1 PL per 1 RP entry

Regards,
S.