Allow generation of combined IPv4/IPv6 lists

[ktims]

Currently bgpq3 makes address family selection mutually exclusive. I propose allowing generation of mixed lists.

I am not sure which underlying platforms support mixing address families, but it is supported in JunOS both with prefix-lists and route-filters, and would also be useful for external integration using e.g. JSON or user defined output to not have to merge the lists externally. For platforms that don't support combined lists, perhaps it could be implemented by generating the configuration for the two lists in one pass.

[snar]

On Tue, Jan 11, 2022 at 11:25:39AM -0800, Keenan Tims wrote:

Currently bgpq3 makes address family selection mutually exclusive. I propose allowing generation of mixed lists.

What is the use-case for such lists ? Looks like my imagination fails to find one:

• on BGP peering you shall have different sessions for different families to make sure that next-hop is actually reachable (and it implies different policies/prefix-lists per family)
• for filtering purposes, you shall have different filters applied per family.
• something else ?

I am not sure which underlying platforms support mixing address families, but it is supported in JunOS both with prefix-lists and route-filters, and would also be useful for external integration using e.g. JSON or user defined output to not have to merge the lists externally. For platforms that don't support combined lists, perhaps it could be implemented by generating the configuration for the two lists in one pass.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: @.**>

[ktims]

We have built our existing templates around combined policy-statements. Usually other route policy is shared between address families (e.g. communities, any peer-specific policy tweaks, etc.), and I don't see any reason to double the amount of boilerplate and double the amount of work when policy changes are needed if the router can intelligently treat all prefixes generically as objects. If it's necessary to have AF-specific policy, it seems more logical to me to put that exception as a policy rule, rather than having an entirely separate policy. It seems to me to reduce the opportunity for human error and simplify/shrink the configuration to have one place that it all lives.

Our existing infrastructure for maintaining these filters is aging and unsupported, and I wanted to use bgpq3 to replace some existing manual procedures and as part of renewed automation, but without changing the templates entirely. Dealing with the limitation on the automation side is straightforward, but for manual use it's pretty cumbersome to manually stitch the lists together.

FWIW I do have several (uncommon) BGP sessions that carry both IPv6 and IPv4 routes for..legacy..reasons.

[snar]

Ok, makes sense. Another scenario when such filters may make sense is application-level access-lists (nginx, squid and so on), so, it's implemented and uploaded to github head.

Notes:

• implemented for Juniper, JSON and User-Defined formats only
• is not compatible with minimum prefix length (-m) and more-specific (-r/-R) filters.
• for Juniper, order of prefixes in generated prefix-list may be not the same as in juniper output. Example: prefix-list generated with bgpq3 -Jx as9002 ends with:

policy-options { replace: prefix-list NN { [....] 195.133.47.0/24; 213.178.155.0/24; 213.226.112.0/24; 213.226.114.0/24; 2001:67c:2fe4::/48; 2a02:2d8::/32; 2a07:7940:fffc::/48; } }

(all ipv6 prefixes are placed after ipv4), however, show | compare on router shows prefix 2001:67c:2fe4::/48 placed before 213.178.155.0/24:

•   195.133.47.0/24;
  

•   2001:67c:2fe4::/48;
  

•   213.178.155.0/24;
  

•   213.226.112.0/24;
  

•   213.226.114.0/24;
  

•   2a02:2d8::/32;
  

•   2a07:7940:fffc::/48;
  

• }

As the same misorder does not happen with route-filter-lists (-Jxz) and route-filters, let me consider this as non-issue.