11 Replies Latest reply on Jul 11, 2014 8:32 AM by noor

    BGP Default Router Redistribution OSPF

    pta200 New Member

      I have two 3448 edge routers and a core 1544. How do I redistribute a BGP learned default route into OSPF in the first 3448 such that when the static redistributed default route route drops out of the second 3448 the 1544 will send it's default traffic directly to the first 3448 rather then second 3448? Seems like the redistributed default route in both 3448 shows the same admin/metric values in the 1544 E2 {110/10] no matter how I tweak the BGP redistribution. If I add a metric to the default-information-originate command to either 3448 I can force a preference to one router, but then the 1544 will always send default traffic the same 3448 regardless of whether it has the route or is learning from the other 3448.

        • Re: BGP Default Router Redistribution OSPF
          jayh Hall_of_Fame

          Your description is a bit unclear.  A diagram might help.

           

          Part of the problem is that you can't technically redistribute a default route into OSPF.  You can default-information originate, set metrics on this route, and make it conditional with a route-map.  Default-information originate doesn't actually redistribute.  It injects a default if one exists from any routing protocol. Therefore metrics applied to BGP redistribution affecting other BGP-redistributed routes won't apply.

           

          You can specify a metric in the default-information originate command, and also add the keyword "always" which will advertise a default into OSPF even if one doesn't exist on the router. Without "always" the default route will be withdrawn from OSPF if there isn't a default on the router (such as if BGP goes down in your example). You can also specify a metric and metric type 1 or 2 on the default-information originate line.

           

          It sounds like route-maps may be what you're looking for but it's not clear to me what you are trying to accomplish without some kind of diagram or sketch.  Even ASCII-art would help. You may be able to just tweak the metrics on the default-information originate statements as well.

            • Re: BGP Default Router Redistribution OSPF
              pta200 New Member

              So 3448A and 3448B each have an internet connection and redistribute a default route via ospf to the 1544. 3448A has it's default route via BGP from the carrier. 3448B has default static route. I want the 1544 to prefer the default route out 3448B unless 3448B's default route drops in which case it should go out 3448A. The problem as you described is that default-information injects the route from any routing protocol. So when I add a high metric to the default-information command on 3448A so 3448B is preferred the 1544 will always prefer going out 3448B even if 3448B loses it's default static route. This is because the 3448B picks up the route from 3448A, changes the metric and sends on to the 1544. The only way this would work I guess is to use a route map as you described and filter out the default route from 3448A to 3448B. How do I apply a route-map to OSPF?

               

              thanks,

              Paolo

                • Re: BGP Default Router Redistribution OSPF
                  jayh Hall_of_Fame

                  Aha!  Here's the problem.  On 3448B because you have a default static, it will be injected into OSPF regardless of whether 3448B can actually reach the Internet. 

                   

                  What you need to do is make 3448B's default route tracked so that if the ISP becomes unreachable the default route is withdrawn.  For the example below assume your side of the link to the provider on 3448B is 172.16.1.2 and their gateway is 172.16.1.1 .  Substitute your actual IPs for the link out to 3448B's ISP.

                   

                  probe default-probe icmp-echo

                    destination 172.16.1.1

                    source-address 172.16.1.2

                    period 1

                    timeout 500

                    tolerance consecutive fail 3 pass 60

                    no shutdown

                   

                  track default-track

                    test if probe default-probe

                    no shutdown

                   

                  ip route 0.0.0.0 0.0.0.0 172.16.1.1 track default-track 

                   

                  Now, configure your default-information originate as part of OSPF on both routers, without the always keyword. On 3448A assign your default-information originate a higher metric.  The 1554 will see both default routes but prefer the default to 3448B due to the lower metric.  Should 3448B become unable to ping its gateway, after three seconds its default route will disappear and it will withdraw it from OSPF.  Then the injected default from 3448A will be used. 

                   

                  Note that the pass probe requires 60 consecutive pings to recover -- one minute of solid connectivity.  This holds down the route if the link is flaky and prevents route churn.  Of course you can tweak these metrics as you see fit.

                   

                  One key part of the configuration is to specify the source IP of the interface out to 3448B's ISP in the probe statement.  Otherwise if the interface goes down the probe will go over the 1544, out 3448A's default, across the Internet, and back to the target and you'll get a false "UP" status and route oscillation.

                    • Re: BGP Default Router Redistribution OSPF
                      pta200 New Member

                      The default static route on 3448B is tracked and does drop out when the track changes to fail. Butthe 3448B is still receiving the default route from 3448A though which it also passes on to the 1544 with a different metric then the 1544 gets from 3448A since 3448A default-originate has a metric added. So the 1544 continues to send default traffic to the 3448B but at this point 3448B will send to 3448A via the OSPF learned default route. It would preferable if 1544 just sent the traffic to 3448A instead.

                        • Re: BGP Default Router Redistribution OSPF
                          jayh Hall_of_Fame

                          Try changing the injected defaults to metric-type 1 so that the internal OSPF costs are added.

                           

                          default-information originate metric-type 1

                           

                          Also verify that bandwidth statements on the interfaces are such that the 1554 sees the same cost to both 3448s.

                          1 of 1 people found this helpful
                            • Re: BGP Default Router Redistribution OSPF
                              pta200 New Member

                              Should there still be a metric on 3448? If I take there is no metric on 3448A the 1544 seems the default routes from both 3448 A & B as equal so keeps which ever it got first. Also if 3448B is installed in the 1544, drops out and comes back the 1544 will remain on 3448A unless 3448A drops out

                                • Re: BGP Default Router Redistribution OSPF
                                  jayh Hall_of_Fame

                                  It is odd that 3448B is propagating the default from 3448A back out, this could be a bug.  All in same area 0, equal bandwidth interfaces?

                                   

                                  A high metric from 3448A is fine.  What metric-type 1 does is to add the internal OSPF cost to the external cost which is what you want to have routes originated from A look closer to A.

                                   

                                  One gotcha, if these are gigabit links, is that the default reference bandwidth for a cost of 1 is 100Mbps so anything greater than 100 Mbps isn't properly weighted in terms of best path.  You can fix this with auto-cost reference-bandwidth 10000 in OSPF configuration which will set the "fastest" link to 10Gbps and make a gigabit link a cost of 10.  Make sure you apply this to every router participating in OSPF.

                                  1 of 1 people found this helpful
                                    • Re: BGP Default Router Redistribution OSPF
                                      pta200 New Member

                                      The public subnets on both 3448 are in different areas. The local private LAN all three rotuers is area 0. So that's likely the problem right?

                                        • Re: BGP Default Router Redistribution OSPF
                                          jayh Hall_of_Fame

                                          Are you speaking OSPF with your providers?  Why are these in OSPF? Are any of the default routes displayed as "IA" in "show ip route"?

                                            • Re: BGP Default Router Redistribution OSPF
                                              pta200 New Member

                                              No BGP with one provider and static route to the other (Time Warner Cable). I have a lot of other networks in my office so I'm using OSPF to relay them across the various routers. Right now the default static routes show as E2 when metric-type is 2 or E1 when metric-type is 1 in the default originate command.

                                                • Re: BGP Default Router Redistribution OSPF
                                                  Employee

                                                  pta200 -

                                                  I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post to unmark it and select another in its place with the applicable buttons.  If you have any additional information on this that others may benefit from, please come back to this post to provide an update.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

                                                   

                                                  Thanks,

                                                  Noor