cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
New Contributor

Redistributed OSPF --> BGP Routes Not Honoring Metric

I am having an issue where the metrics in my OSPF-->BGP redistribution commands to not seem to be honored. I have a cascading metric for each site redistributing default routes, but when received, it's always default eBGP 20.

Site 3:

router ospf

  network 192.168.200.0 0.0.0.3 area 0 (<-- Transit between my device and client's)

  network 0.0.0.0 0.0.0.0 area 0

  redistribute bgp subnets

!

router bgp 65xxx

  neighbor xxx.xxx.xxx.xxx

    remote-as xxxx

    no shutdown

    exit

  address-family ipv4

    network 192.168.200.0 mask 255.255.255.252

    redistribute ospf metric 200 (<---This site is a last resort, hence the high metric)

    redistribute static metric 200

    neighbor xxx.xxx.xxx.xxx

      soft-reconfiguration inbound

      no shutdown

      exit

    exit

What I am receiving at remote sites:

B0.0.0.0/0 [20/0/0] (xxxx) via xxx.xxx.xxx.xxx, eth 0/1

Goal is to redistribute successfully with a weight that is received at all other remote sites. And yes, every site is redistributing its default route that is received (no statically set routes) via my client's OSPF...

Labels (1)
0 Kudos
1 Reply
Highlighted
Honored Contributor
Honored Contributor

Re: Redistributed OSPF --> BGP Routes Not Honoring Metric

20 is the administrative distance for eBGP, not its metric. It will be used to choose between eBGP routes and those from another routing protocol. It is rarely a good idea to change administrative distance, but it can be done.

If you used iBGP with the remote sites having the same AS, you could use local-preference.

eBGP won't look at MED or metric by default from a different origin AS. Cisco has a knob to allow this called "always-compare-med" but I don't know the Adtran equivalent if one exists.

For eBGP you can use a route-map and add prepends to de-preference the routes.

You could also set a community and then map that community to adjust the metric on the other end.

If the remote site is comparing the default from eBGP and that from another routing protocol, you'll probably need to use communities.

Be careful redistributing defaults, it's easy to get undesired behavior. A big picture of the problem you're trying to solve with this configuration might help. There may be a better way to accomplish the end goal.