Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Any way to filter OSPFv3 routes through GUI in 2.4.4-p3?

    Scheduled Pinned Locked Moved FRR
    6 Posts 2 Posters 479 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      hpxca
      last edited by hpxca

      Hello,
      I noticed that in the GUI there are extensive options for route filtering of redistributed routes for OSPFv2 (IPv4) but I see nothing under the OSPFv3 (IPv6) configuration tab. Is this unsupported by FRR version 6.X or just not implemented in the package? Can I filter on a route-map via the raw-config (which is non-ideal I guess but if it is the only way....)

      Thanks!

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        I can't remember if I didn't implement that yet because it didn't work or because I just hadn't got around to it yet.

        Give it a try in the raw config and see what happens. It may work, it may not. OSPFv3 support in FRR can be a bit spotty. For example it only supports a single area.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • H
          hpxca
          last edited by

          Hi Jim,
          I have tested this and it does appear to work. Note that I have removed/changed some IP addresses in this example to maintain our privacy in some cases as this is a public post. This is on an XG-7100:

          ospf6d.conf

          password <removed>
          log syslog
          interface lagg0.4081
          interface lagg0.4082
          
          router ospf6
            router-id A.B.C.D
            area 0.0.0.0 range 2606:XXXX:0:10::/127 cost 1
            area 0.0.0.0 export-list MATCH-ALL
            interface lagg0.4081 area 0.0.0.0
            area 0.0.0.0 range 2606:XXXX:0:11::/127 cost 1
            area 0.0.0.0 export-list MATCH-ALL
            interface lagg0.4082 area 0.0.0.0
            redistribute static route-map OSPF6-OUT
            timers throttle spf 5000 10000 100000
          
          # Prefix Lists
          ipv6 prefix-list MATCH-DEFAULT seq 10 permit ::/0
          ipv6 prefix-list MATCH-DEFAULT description Match the default route
          ipv6 prefix-list MATCH-ALL seq 10 permit any
          ipv6 prefix-list MATCH-ALL description Match all routes
          
          # Route Maps
          route-map OSPF6-OUT deny 10
            match ipv6 address prefix-list MATCH-DEFAULT
          route-map OSPF6-OUT permit 20
            match ipv6 address prefix-list MATCH-ALL
          

          staticd.conf

          password <removed>
          
          # Fallback routes in case of an OSPF issue
          
          ipv6 route ::/0 fe80::a60c:c3ff:fea7:7043 lagg0.4081 200
          ipv6 route ::/0 fe80::a60c:c3ff:fefb:2ec2 lagg0.4082 200
          
          # Pin the larger IPv6 route as a static to null0 and redistribute that
          
          ipv6 route 2606:XXXX:2::/48 Null0
          

          On the Cisco:

          Type-5 AS External Link States
          
          ADV Router      Age         Seq#      	Prefix
          
          A.B.C.D     61          0x80000001  2606:XXXX:2::/48
          

          The logic here is that I have allocated that entire /48 block for use on the LAN side of the firewall, but presently only part of it is in use. In order to ensure the full block is allocated I pinned a Null0 route as a static in FRR and then want to redistribute that rather then redistributing the connected routes. This also saves from getting a potentially long list of /64s in the routing table. I needed to make sure those fallback default routes got filtered though.

          But it all seems to work OK.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            You should be able to do this in the GUI on the latest FRR package version (0.6.4)

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • H
              hpxca
              last edited by hpxca

              I have updated to 2.4.5 and pulled in the latest FRR package (0.6.4_5) as part of that update. Unfortunately, the functionality described in the original post still cannot be recreated in with the GUI properly even with this version. Manual raw config is required.

              The main issue here is that the "prefix-list" and "route-map" settings are "global" in the FRR configuration. More specifically they are not tied to OSPF or OSPF6 specifically like some of the others are. Because OSPF6 prefix lists and route-maps must begin with "ipv6" instead of "ip" this causes problems, especially in cases where the entry is ambiguous and cannot be obviously classified as being ipv4 or ipv6.

              Take this line for example from the OP:

              ipv6 prefix-list MATCH-ALL seq 10 permit any
              

              In so far as I can tell there's no way to create this line in the GUI. Creating a prefix list called "MATCH-ALL" with a sequence of "10" and an action of "permit" with a network of "any" will generate:

              ip prefix-list MATCH-ALL seq 10 permit any
              

              This will be put in ospfd.conf and not ospf6d.conf. As a result. if you try to use your MATCH-ALL prefix list in an ipv6 route map you run into problems.

              I am honestly unsure if you can mix and match..For example would the below work?

              route-map OSPF6-OUT deny 10
                match ipv6 address prefix-list MATCH-DEFAULT
              route-map OSPF6-OUT permit 20
                match ip address prefix-list MATCH-ALL
              

              If that's put in ospf6d.conf I don't think it would..

              A second problem I found is that IPv6 prefix list entries are being put in the wrong file in general. For example. Create a prefix list entry called "MATCH-V6-DEFAULT", sequence 10, action permit and network ::/0.

              The GUI does properly detect this as a IPv6 address and creates the entry with the correct prefix, unlike the ambiguous case above:

              in ospfd.conf

              ipv6 prefix-list MATCH-V6-DEFAULT seq 10 permit ::/0
              

              The problem is, this entry is added to the ospfd.conf instead of the ospf6d.conf like it should be. The same thing happens if you create a route-map using this prefix-list. The route map is also put into the wrong file and generated incorrectly:

              in ospfd.conf

              route-map OSPF6-OUT deny 10
                match ip address prefix-list MATCH-V6-DEFAULT
              

              When this should be:

              in ospf6d.conf

              route-map OSPF6-OUT deny 10
                match ipv6 address prefix-list MATCH-V6-DEFAULT
              

              The difference is the file it's in and the "match ipv6" vs "match ip".

              Erik

              1 Reply Last reply Reply Quote 0
              • H
                hpxca
                last edited by

                I actually see now flipping though the forums both of these have been reported before.

                The first issue can be worked around by using "any6" instead of "any", but I think it'll still get dropped into the wrong file. I don't think there's any workaround for the 2nd but it's be previously mentioned.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.