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

    zebra Route Filtering

    Scheduled Pinned Locked Moved FRR
    13 Posts 3 Posters 2.0k Views 4 Watching
    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.
    • M Offline
      Musashi @michmoor
      last edited by Musashi

      @michmoor

      we have (access) only one area

      The goal is to filter IPs coming from OSPF corresponding to a specific route-map called IN (with permits and denies) to bring them back into the kernel.

      M 1 Reply Last reply Reply Quote 0
      • M Offline
        michmoor LAYER 8 Rebel Alliance @Musashi
        last edited by

        @Musashi
        So the routes exist already in OSPF?
        You are importing connected and static routes but passing them through a filter (route-map)
        So whats the problem exactly?

        Firewall: NetGate,Palo Alto-VM,Juniper SRX
        Routing: Juniper, Arista, Cisco
        Switching: Juniper, Arista, Cisco
        Wireless: Unifi, Aruba IAP
        JNCIP,CCNP Enterprise

        G 1 Reply Last reply Reply Quote 0
        • G Offline
          gamba @michmoor
          last edited by gamba

          @michmoor

          I am a coworker of @Musashi, we are hosted on a campus.

          Our OSPF router is currently on linux, and we use

          ip protocol ospf route_map …
          

          to filter incoming OSFP route, accepting only IP addresses matching our network and IP from private networks used for wifi networks.

          We don't find how to specify ip protocol ospf route_map in the pfsense web interface. Is it possible ?

          Sorry if we are unclear, we are clearly out of our comfort zone when dealing with ospf stuff.

          M 1 Reply Last reply Reply Quote 0
          • M Offline
            michmoor LAYER 8 Rebel Alliance @gamba
            last edited by

            @gamba said in zebra Route Filtering:

            o filter incoming OSFP route,

            im a bit confused as to what you are trying to do here.
            you can only filter ospf routes (LSAs) as they leave an Area or come into an Area.
            But you only have acess to only one area? So this means your network is connected to the backbone area and you are in a non-backbone area, yes?
            If so, filter at your ABR

            Firewall: NetGate,Palo Alto-VM,Juniper SRX
            Routing: Juniper, Arista, Cisco
            Switching: Juniper, Arista, Cisco
            Wireless: Unifi, Aruba IAP
            JNCIP,CCNP Enterprise

            G 1 Reply Last reply Reply Quote 0
            • G Offline
              gamba @michmoor
              last edited by

              @michmoor

              Some routes already exist in OSPF, and we provide others by redistributing stating/connected routes.

              Some routes received by OSPF (private networks) clash with internal routing in our network.
              We have to filter those route out and not consider them.

              For instance, we use 172.31.0.0/16 internally, and this network is also received through OSPF.

              We actually do this filtering at the zebra level with ip protocol ospf route_map ….
              But we can't find the option in the pfsense gui for frr to do that.

              I hope this clarifies our problem.

              G 1 Reply Last reply Reply Quote 0
              • G Offline
                gamba @gamba
                last edited by

                @michmoor

                You are right : our router is an ASBR in a non backbone area.
                We have to filter some routes that we reveive from OSPF, and we have no control on the ABR in the zone.

                M 1 Reply Last reply Reply Quote 0
                • M Offline
                  michmoor LAYER 8 Rebel Alliance @gamba
                  last edited by michmoor

                  @gamba
                  There are a couple of design decisions that you will need to make in the future regarding your set up If you have IP overlap we wont discuss all of them for your problem but you should be aware of it so i shall mention it below.

                  If you want to limit the amount of OSPF advertisements into your Area (non-backbone) then highly recommend making it a stub. Considering you are redistributing routes into your Area as you have an ASBR then i recommend NSSA totally stubby. In this way you will not see any external routes from the backbone AND you will not receive inter-area routes. you will get a default route injected into your Area only which should suffice for your routing needs outside the ospf area.

                  That should simplify the routing quite a bit within your area. You will not see the conflicting prefixes from the backbone as your area only knows about the intra-area routes and a default route from the ABR. External destinations injected into your area will be by your ASBR in which case routing to those external areas is handled all within your Area.
                  edit: Just to make sure I'm expanding on this clearly. Even though within your non-backbone area you never seen IP overlap issues the backbone area still sees your area routes as that is the nature of OSPF flooding inter-area. Thats why its critical to filter your routes on the ABR - egress your area. All of this is not ideal and the long term solution should be BGP as i outlined below.

                  The other design decision is to break up these OSPF areas with BGP. You run eBGP between you and the other site. Run OSPF within the LAN(assuming its larger enough to warrant that). In this way, BGP being a policy-driven protocol more so then a routing one, you are able to control what gets announced by you and the benefit of steering traffic the way you want it.

                  That said, as i mentioned, you can only filter routes into an Area or routes leaving an area. Thats it.
                  Create your route-maps in pfsense by going to Services > FRRGlobal Settings > Route Maps
                  Then apply that route-map on your ASBR or your ABR under
                  Services > FRR> OSPF> edit Areas

                  Firewall: NetGate,Palo Alto-VM,Juniper SRX
                  Routing: Juniper, Arista, Cisco
                  Switching: Juniper, Arista, Cisco
                  Wireless: Unifi, Aruba IAP
                  JNCIP,CCNP Enterprise

                  G M 2 Replies Last reply Reply Quote 0
                  • G Offline
                    gamba @michmoor
                    last edited by

                    @michmoor
                    You are perfectly correct on the ospf side, but we have no liberty to change the ospf topology, or even to add a zone.

                    Furthermore, we need some of the routes provided by ospf.
                    Zebra is an adequate choice to filter incoming routes, we alreday do that.

                    Our question remains : how to to ip protocol ospf route_map XXX in the frr gui in pfsense, that is all :-)

                    M 1 Reply Last reply Reply Quote 0
                    • M Offline
                      michmoor LAYER 8 Rebel Alliance @gamba
                      last edited by

                      @gamba I answered it above ….

                      Firewall: NetGate,Palo Alto-VM,Juniper SRX
                      Routing: Juniper, Arista, Cisco
                      Switching: Juniper, Arista, Cisco
                      Wireless: Unifi, Aruba IAP
                      JNCIP,CCNP Enterprise

                      G 1 Reply Last reply Reply Quote 0
                      • G Offline
                        gamba @michmoor
                        last edited by

                        @michmoor Perfect, thank you very much.

                        1 Reply Last reply Reply Quote 0
                        • M Offline
                          Musashi @michmoor
                          last edited by

                          @michmoor thanks for your time

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