Mailing List Archive: Quagga: Users

Prefer "local" BGP route over OSPF redistributed route

Index | Next | Previous | View Threaded

doug at warner

Aug 10, 2012, 2:00 PM

Post #1 of 6 (1639 views)
Permalink

Prefer "local" BGP route over OSPF redistributed route

We are transitioning a large OSPF area 0 network to be linked by iBGP. The
OSPF is bridged together by VPN tunnels and I've set an ospf cost on the VPN
interfaces to be 100 so they are preferred less over the local routes and make
the longer links actually seem longer.

I'm trying to bring a VPN tunnel from a new location into two locations that
are already running OSPF between them, but one endpoint is ending up having
the route preferred all the time, so the other location routes everything
across the VPN to go out that BGP'd link.

Some art might help:
10.128.0.0/22
----------- SFJ
/ |
10.134.0.0/22 / gre/iBGP |
RZC / gre/OSPF (cost 100)
\ |
\ gre/iBGP |
\ |
----------- ATL
10.136.0.0/24

What I'm seeing is:
-- SFJ will see the iBGP from RZC and announce it into OSPF

# show ip route 10.138.0.0
Routing entry for 10.138.0.0/22
Known via "bgp", distance 200, metric 1, best
Last update 00:36:55 ago
* 172.31.254.29, via gre1

# show ip bgp 10.138.0.0
BGP routing table entry for 10.138.0.0/22
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
172.31.254.29 (metric 1) from 172.31.254.29 (10.138.0.253)
Origin incomplete, metric 1, localpref 100, valid, internal, best
Last update: Fri Oct 1 10:13:32 1971

-- ATL will see the iBGP from RZC, but prefer the OSPF routes from SFJ

# show ip route 10.138.0.0
Routing entry for 10.138.0.0/22
Known via "ospf", distance 110, metric 210, best
Last update 00:11:10 ago
* 172.31.254.137, via gre1

# show ip bgp 10.138.0.0
BGP routing table entry for 10.138.0.0/22
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.31.254.31
Local
172.31.254.31 (metric 1) from 172.31.254.31 (10.138.0.253)
Origin incomplete, metric 1, localpref 100, valid, internal
Last update: Fri Aug 10 15:39:05 2012

Local
172.31.254.137 from 0.0.0.0 (10.136.0.248)
Origin incomplete, metric 210, localpref 100, weight 32768, valid,
sourced, best
Last update: Fri Aug 10 16:08:45 2012

Any ideas if what I'm trying to do here is possible?
And as an aside, I'd even like to have /multiple/ gre tunnels running BGP
between colos and use ECMP via OSPF between them if I can (that's the main
reason we have a large area 0 currently).

-Doug

Attachments:

signature.asc (0.19 KB)

unki at netshadow

Aug 10, 2012, 10:44 PM

Post #2 of 6 (1608 views)
Permalink

Re: Prefer "local" BGP route over OSPF redistributed route [In reply to]

> Any ideas if what I'm trying to do here is possible?

Basically yes. It's all about administrative distance - how the routing
instance distinguish between routing protocols.

iBGP has a AD of 200, OSPF 110. So OSPF wins the race even if the route
metric would be worse than the one from iBGP. See [1] for more.

You can modify the AD in the router ospf/bgp sections by using
"distance". But make sure you have a continuous concept on all your
routers - otherwise you may end up in the AD hell.

Or you let your BGP routes appear as external - then they would have an
AD of 20.

Cheers,
Andreas

[1]
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml

_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users

doug at warner

Aug 13, 2012, 10:59 AM

Post #3 of 6 (1605 views)
Permalink

Re: Prefer "local" BGP route over OSPF redistributed route [In reply to]

On 08/11/2012 01:44 AM, Andreas Unterkircher wrote:
>> Any ideas if what I'm trying to do here is possible?
>
> Basically yes. It's all about administrative distance - how the routing
> instance distinguish between routing protocols.
>
> iBGP has a AD of 200, OSPF 110. So OSPF wins the race even if the route metric
> would be worse than the one from iBGP. See [1] for more.
>
> You can modify the AD in the router ospf/bgp sections by using "distance". But
> make sure you have a continuous concept on all your routers - otherwise you
> may end up in the AD hell.
>
> Or you let your BGP routes appear as external - then they would have an AD of 20.
>
> Cheers,
> Andreas
>
> [1]
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml

Thanks for the tip; I was fighting with the distances in BGP and the
redistribute metrics for BGP in OSPF and wasn't getting anywhere. Switching
these from iBGP to eBGP made things work exactly as I expected, thanks!

-Doug

Attachments:

signature.asc (0.19 KB)

doug at warner

Aug 13, 2012, 3:38 PM

Post #4 of 6 (1601 views)
Permalink

Re: Prefer "local" BGP route over OSPF redistributed route [In reply to]

On 08/13/2012 01:59 PM, Doug Warner wrote:
> On 08/11/2012 01:44 AM, Andreas Unterkircher wrote:
>>> Any ideas if what I'm trying to do here is possible?
>>
>> Basically yes. It's all about administrative distance - how the routing
>> instance distinguish between routing protocols.
>>
>> iBGP has a AD of 200, OSPF 110. So OSPF wins the race even if the route metric
>> would be worse than the one from iBGP. See [1] for more.
>>
>> You can modify the AD in the router ospf/bgp sections by using "distance". But
>> make sure you have a continuous concept on all your routers - otherwise you
>> may end up in the AD hell.
>>
>> Or you let your BGP routes appear as external - then they would have an AD of 20.
>>
>> Cheers,
>> Andreas
>>
>> [1]
>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml
>
> Thanks for the tip; I was fighting with the distances in BGP and the
> redistribute metrics for BGP in OSPF and wasn't getting anywhere. Switching
> these from iBGP to eBGP made things work exactly as I expected, thanks!
>

So now it seems I'm fighting a slightly different problem; where the OSPF
route injected into my BGP process is taking precedence over my learned eBGP
route.

# show ip bgp 10.138.0.0
BGP routing table entry for 10.138.0.0/22
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.31.254.29
64526
172.31.254.29 from 172.31.254.29 (10.138.0.253)
Origin incomplete, metric 1, localpref 100, valid, external
Last update: Mon Oct 4 13:01:29 1971

Local
10.128.1.47 from 0.0.0.0 (10.128.0.247)
Origin incomplete, metric 20, localpref 100, weight 32768, valid,
sourced, best
Last update: Mon Oct 4 12:59:17 1971

Is this changed by the "localpref" setting? I've tried setting the "distance
bgp" values, but I don't understand whether this affects the local BGP
database, the values it exports, or what.

I see I'm not the only one that had this problem before [1], but that thread
didn't go anywhere.

-Doug

[1] http://www.gossamer-threads.com/lists/quagga/users/20000

Attachments:

signature.asc (0.19 KB)

quagga-users at alexis

Aug 14, 2012, 6:25 AM

Post #5 of 6 (1605 views)
Permalink

Re: Prefer "local" BGP route over OSPF redistributed route [In reply to]

On Aug 13, 2012, at 6:38 PM, Doug Warner wrote:
> On 08/13/2012 01:59 PM, Doug Warner wrote:
>> On 08/11/2012 01:44 AM, Andreas Unterkircher wrote:
>>>> Any ideas if what I'm trying to do here is possible?
>>>
>>> Basically yes. It's all about administrative distance - how the routing
>>> instance distinguish between routing protocols. [...]
>>>
>>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml
>>
>> Thanks for the tip; I was fighting with the distances in BGP and the
>> redistribute metrics for BGP in OSPF and wasn't getting anywhere. Switching
>> these from iBGP to eBGP made things work exactly as I expected, thanks!

This is not a good idea, though it can be made to work if you're careful. If you really insist on using BGP, you should just change the admin distance of the protocol instead of using ebgp. While you're at it, change the timers so convergence is faster. And since this is quagga, consider running a separate BGP for this internal routing.

However, you're really making the wrong choice here. And you're doing it without understanding what you're doing, which is ultimately likely to land you in trouble.

> So now it seems I'm fighting a slightly different problem; where the OSPF
> route injected into my BGP process is taking precedence over my learned eBGP
> route.
> [...]
> Is this changed by the "localpref" setting? I've tried setting the "distance
> bgp" values, but I don't understand whether this affects the local BGP
> database, the values it exports, or what.

The distance is exactly that - the admin distance, which determines which route actualy goes into the KERNEL route table if multiple protocols each have a route. It has no bearing on imported routes or any other decision made within a single protocol.

Read the link Andreas sent you, completely. Then go back to it in a couple of days and read it again. Do not confuse distance, metric, weight, and localpref.

Then, when you're finally done, you should really go back to an all-OSPF solution. It's *way* cleaner and easier. If you're worried about number of participating routers or the size of updates over your tunnels, use areas. If you want to control metrics for route selection within OSPF, that's what interface costs are for.

Speaking of which, take note of http://www.gossamer-threads.com/lists/quagga/users/15006 . You can do "ip ospf cost xxx" on real interfaces, or you can use the syntax documented in this link.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users

unki at netshadow

Aug 14, 2012, 10:46 AM

Post #6 of 6 (1598 views)
Permalink

Re: Prefer "local" BGP route over OSPF redistributed route [In reply to]

> So now it seems I'm fighting a slightly different problem; where the OSPF
> route injected into my BGP process is taking precedence over my learned eBGP
> route.

This is then about the BGP best path selection. See [1] or [2].

> # show ip bgp 10.138.0.0
> BGP routing table entry for 10.138.0.0/22
> Paths: (2 available, best #2, table Default-IP-Routing-Table)
> Advertised to non peer-group peers:
> 172.31.254.29
> 64526
> 172.31.254.29 from 172.31.254.29 (10.138.0.253)
> Origin incomplete, metric 1, localpref 100, valid, external
> Last update: Mon Oct 4 13:01:29 1971
>
> Local
> 10.128.1.47 from 0.0.0.0 (10.128.0.247)
> Origin incomplete, metric 20, localpref 100, weight 32768, valid,
> sourced, best
> Last update: Mon Oct 4 12:59:17 1971

I guess here it is the weight attribute. The redistributed prefix from
OSPF weights more than the BGP advertised prefix from neighbor
172.31.254.29 (which is 0). So the path selection can return its result
immediately on the first test.

The weight attribute is local to the router. You would have to use
anroute-map to change the weight on the prefix that you receive from
172.31.254.29. Or a route-map that you apply on redistributing from OSPF
that sets weight back to 0.

Cheers,
Andreas

[1]
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

[2] http://blog.initialdraft.com/archives/702/
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads