8 Replies Latest reply: Nov 11, 2019 11:23 AM by l00pback RSS

    Reg Redistribution of IGP into BGP

    Yugandhar

      Hi ,

       

      I need some help reg redistribution of IGP into BGP concept.

       

      As IGP is unstable and any fluctuation in the IGP network would case the BGP   updates to be sent frequently to the BGP peers.

       

      So would like to check any other alternative to redistribute IGP into BGP in a way that any changes in the IGP network don't disturb the BGP session

       

      Thanks,

      Yugandhar.

        • 1. Re: Reg Redistribution of IGP into BGP
          l00pback

          Depends what you are trying to achieve with your IGP->BGP route redistribution.
          Besides plain redistribution, there are other ways to propagate your address range to BGP. Static route to null + redistribute or aggregate-address are some tricks to start with.

          • 2. Re: Reg Redistribution of IGP into BGP
            Yugandhar

            Thank you

             

            R1

            ====

            router bgp 64512

            neighbor 1.1.1.1 remote-as 1111

            redistribute static

            no auto-summary

             

            ip route 10.10.10.0 255.255.255.0  null0

             

            router ospf 1

            network 10.10.10.0 0.0.0.255

             

            Now when we redistribute the static routes with Null0 .....R1 receives the traffic destined to 10.10.10.10 from its peer 1.1.1.1  then it would do a route lookup to know the next hop  for 10.10.10.10 and it matches the entry for static route with next-hop set to null interface and drops the traffic.

             

            Please let me know if my above statement is correct ?.

             

            Thanks,

            Yugandhar.

            • 3. Re: Reg Redistribution of IGP into BGP
              Peter McKenzie

              here is an interesting discussion by someone more knowledgeable than my good self

               

              BGP does not redistribute a static default route unless the

              default-information command is used. This protects against someone accidentally

              redistributing a default route in BGP which could potentially be disastrous.


              http://lostintransit.se/2013/06/12/default-routes-in-bgp/?doing_wp_cron=1573462324.0278959274291992187500


              • 4. Re: Reg Redistribution of IGP into BGP
                Yugandhar

                Thank you Peter,

                 

                Here in my scenario, we are not redistributing the Default Route. Instead advertising a IGP network into BGP via Static route with null0 as next-hop.

                • 5. Re: Reg Redistribution of IGP into BGP
                  Elvin Arias

                  To avoid instabilities in the routing update process, if design allows it, create a summary address holding all individual components and advertise it into BGP.

                   

                  In this case, if individual component routes fail, it will not trigger a change in BGP, unless all components go down, in that case, BGP will send a withdrawal message.

                   

                  Elvin

                  • 6. Re: Reg Redistribution of IGP into BGP
                    l00pback

                    The static route for 10.10.10.0/24 will be matched only when there are no more specific routes available. With this trick, you attract traffic for the full /24 but at the same time you need to have more specific routes that will further steer traffic downstream.

                     

                    Going back to your initial objective, redistributing the /24 static route will provide stability throughout your BGP fabric as that static route will be always present but it can also blackhole traffic in case your more specific routes are not available.

                    • 7. Re: Reg Redistribution of IGP into BGP
                      Yugandhar

                      Thank you

                       

                      Here is my config :-

                       

                      R1

                      ====

                      router bgp 64512

                      neighbor 1.1.1.1 remote-as 1111

                      redistribute static

                      no auto-summary

                       

                      ip route 10.10.10.0 255.255.255.0  null0

                      ip route 172.16.0.0 255.255.0.0  null0

                       

                      int fa0/1

                      ip add 10.10.10.1 255.255.255.0

                       

                      router ospf 1

                      network 10.10.10.0 0.0.0.255

                       

                      R2

                      ====

                       

                      int fa0/1

                      ip add 10.10.10.2 255.255.255.0

                       

                      router ospf 1

                      network 10.10.10.0 0.0.0.255

                      network 172.16.0.0 0.0.255.255

                       

                       

                      So if R1 receives any packet destined for any host in 10.10.10.0/24 network or 172.16.0.0/16 its going to drop as it matches static null route.

                       

                      To avoid this, we may have to change the static route stmt to 10.0.0.0 255.0.0.0 null0 and 172.16.0.0 255.240.0.0 null 0  or change the network advertisements statements in OSPF so that it doesn't match exactly the static route statements.

                       

                      Thanks,

                      Yugandhar.

                      • 8. Re: Reg Redistribution of IGP into BGP
                        l00pback

                        Well, in your setup, the 10.10.10.0/24 is directly connected, so its static route will never be installed into the RIB because the connected /24 has AD of 0. It does not make sense to have the static route on the first place. You just inject into BGP the connected /24.

                         

                        The 172.16.0.0/16 situation is different and it looks that you will receive it through OSPF.