Different routing than the one in the routing table

[peter_jevos]

Hi , i have a strange behaviour in the routing

I'm running EBGP and OSPF on my router, because there are more path to the destinations ( BGP paths as the main , OSPF as the backup )

Routing tables is filled, and shows to use BGP path to the destination

However, in the real routing OSPF path is used to reach the desired network.

There are no ACL, no route maps ( only when defining the BGP networks )

What can influence the different routing while the routing table is filled ?

sh ip route:

B        10.1.65.0/25 [100/0] via 10.1.1.1, 3d16h

however different direction is used

Thanks

pet

[Bastien Migette]

Maybe that what you are seeing is that the path to the BGP's route's nexthop is routed against OSPF route, no ? It would help having the whole routing table.

[peter_jevos]

hi thank you for your answer.

here is the ip route against the desired network:

sh ip route 10.1.65.1
Routing entry for 10.1.65.0/25
  Known via "bgp xxx", distance 100, metric 0
  Tag xxx, type internal
  Last update from 10.1.248.1 3d18h ago
  Routing Descriptor Blocks:
  * 10.1.248.1, from 10.1.1.251, 3d18h ago
      Route metric is 0, traffic share count is 1
      AS Hops 4
      Route tag xxx
      MPLS label: none

the traceroute is :

#traceroute 10.1.65.1

Type escape sequence to abort.
Tracing the route to 10.1.65.1

  1 10.100.1.165 36 msec 36 msec 36 msec
  2 10.1.193.1 36 msec 40 msec 36 msec
  3 10.1.65.1 [AS 65313] 36 msec 32 msec 32 msec

the address 10.100.1.165 is the address of the ospf tunnel

I can offer you another output.

thanks

[rsavena14]

Hi Peter,

I think your router is running as it should be. BGP will prioritize IGP if the destination network is present int the IGP routing table. In this case your OSPF.

[Bastien Migette]

may you can add the whole show ip route (remove any sensitive info if any), or sh ip route ospf + show ip route 10.1.1.1 + show ip route connected

I see that your BGP's route AD is 100, so as ospf is 110, OSPF routes are not installed, that is normal, but traffic should follow the BGP path in such case.

maybe you can also parse show ip cef 10.1.65.1 as well.

[rsavena14]

Hi Peter,

To make BGP more prioritize than OSPF, you need to modify the weight instead of the Administrative Distance. This will make BGP priority and OSPF secondary.

Cheers!

[peter_jevos]

Thank you all for your help, however it is as it is:

sh ip route 10.1.65.1

Routing entry for 10.1.65.0/25
  Known via "bgp 65111", distance 100, metric 0
  Tag 65011, type internal
  Last update from 10.1.248.1 3d21h ago
  Routing Descriptor Blocks:
  * 10.1.248.1, from 10.1.1.251, 3d21h ago
      Route metric is 0, traffic share count is 1
      AS Hops 4

Where 10.1.1.251 is the BGp neighbor

sh ip route

...

B        10.1.65.0/25 [100/0] via 10.1.248.1, 3d21h

...

sh ip route ospf doesn't show the network 10.1.65.0

sh ip cef 10.1.65.1
10.1.65.0/25
  nexthop 10.100.1.165 Tunnel473

where tunnel473 is the OSPF tunnel

So there is no need to adjust weight, because AD is lower at the BGP, and therefore BGP has won in the routing process

However, it still routing according the OSPF

thanks

[milan.kulik]

Hi,

IMHO, your output means:

"sh ip route 10.1.65.1

Routing entry for 10.1.65.0/25
Known via "bgp 65111", distance 100, metric 0 - iBGP AD modified
Tag 65011, type internal - received by iBGP, not eBGP
Last update from 10.1.248.1 3d21h ago
Routing Descriptor Blocks:
* 10.1.248.1, from 10.1.1.251, 3d21h ago - BGP next-hop is 10.1.248.1
Route metric is 0, traffic share count is 1
AS Hops 4

Where 10.1.1.251 is the BGp neighbor

sh ip route

...

B        10.3.65.0/25 [100/0] via 10.7.248.1, 3d21h - incorrect, 10.1.65.0/25 would be relevant

...

sh ip route ospf doesn't show the network 10.1.65.0

sh ip cef 10.1.65.1
10.1.65.0/25
nexthop 10.100.1.165 Tunnel473 - showing next-hop to 10.1.248.1

where tunnel473 is the OSPF tunnel"

As the 10.1.248.1 is not a neighbor in a directly connected subnet, your router makes a recursive lookup into the routing table to create a CEF FIB entry.  And the next-hop router might have a different routing table possibly. As the routing is done per-hop, the final traceroute can look totally different an even not contain the next-hop shown by the original BGP routing entry (10.1.248.1).

So I'd recommend to make a traceroute to  10.1.248.1 from your router and compare to your previous traceroutes and routing entries.

BR,

Milan

[peter_jevos]

Hi MIlan

sorry that i confused you

the correct show ip route command should be:

B        10.1.65.0/25 [100/0] via 10.1.248.1, 3d21h

10.1.1.251 is the peer router ( IBGP neigbor ), and it's recieving this route from 10.1.248.1 ( EBGP )

And there are a different ( backup ) tunnel with OSPF with peer 10.100.1.165. There is totaly different ISP

The question is: Why router choose different ( backup OSPF ) route event though its routing table is populated with the different route:( iBGP )

As you can see I changed the IBGP AD to 100 to overcome OSPF AD ( 110 )

Current traceroute is:

#traceroute 10.1.65.1

  1 10.100.1.165 36 msec 36 msec 36 msec

  2 10.1.193.1 36 msec 40 msec 36 msec
  3 10.1.65.1 [AS 65313] 36 msec 32 msec 32 msec

But shoud be through IBGP router 10.1.1.251

  10.1.1.251  1 msec 1 msec 1 msec

  10.1.248.1  1 msec 1 msec 1 msec
   212.2.2.2 8 msec 8 msec 8 msec
   213.1.2.6 24 msec 24 msec 28 msec
   10.1.248.2 [AS XXXX] 24 msec 28 msec 28 msec
   10.1.193.1 32 msec 24 msec 44 msec
   10.1.65.1 [AS 65313] 24 msec 28 msec 28 msec

Thank you

pet

[milan.kulik · Accepted solution]

Hi Peter,

no,

"But should be through IBGP router 10.1.1.251
10.1.1.251  1 msec 1 msec 1 msec
10.1.248.1  1 msec 1 msec 1 msec
212.2.2.2 8 msec 8 msec 8 msec
..."

is incorrect.

Due to

B        10.1.65.0/25 [100/0] via 10.1.248.1, 3d21h

the CEF process is looking for an output interface to send the packet to the next-hop 10.1.248.1

(advertised by the iBGP neighbor 10.1.1.251 - next-hop-self command not used on the neighbor probably)

It makes a recursive lookup into the routing table and finally finds a tunnel interface pointing to that IP address - 10.100.1.165. probably.

Try sh ip route 10.1.248.1 to check.

IMHO, could try to configure

neighbor ... next-hop-self

between your iBGP neighbors, it could fix the path the packets are being sent.

But it could bring another problems - you have to think about possible consequences as only you know your network topology details.

HTH,

Milan

[peter_jevos]

Bingo

that's right. I'm missing nect-hop-self on the 10.1.1.251

The question is how did you find it ? What was the predictor for you? Which output ?

Thank you Milan, all the best

take care

pet

[milan.kulik]

Hi Pet,

the predictor was following:

Looking to the output you provided

"here is the ip route against the desired network:

sh ip route 10.1.65.1
Routing entry for 10.1.65.0/25
Known via "bgp xxx", distance 100, metric 0
  Tag xxx, type internal - i.e., received by iBGP
Last update from 10.1.248.1 3d18h ago
Routing Descriptor Blocks:
  * 10.1.248.1, from 10.1.1.251, 3d18h ago - i.e., neighbor 10.1.1.251 sent the prefix, but next-hop is 10.1.248.1
Route metric is 0, traffic share count is 1
AS Hops 4
Route tag xxx
      MPLS label: none"

As we know that a BGP router default behaviour is to place his own IP address as the next-hop field to the updates sent to eBGP neighbors, but to keep the next-hop unchanged when sending updates to iBGP neighbors, it's quite possible the next-hop-self command was omitted in this case.

(Another possibility would be some next-hop manipulation by a set next-hop command used in an outgoing route-map, but this is a very rare top-level trick.)

See also http://www.cisco.com/en/US/customer/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#bgpnexthop

(or see "BGP Next Hop Attribute" section in this public document http://www.cisco.com/application/pdf/paws/26634/bgp-toc.pdf )

for details.

BR,

Milan