eBGP not working as it should..

[abdul.khan]

we have  created a neighbor between our router in the and our us  office.

BGP neighbor is  10.15.253.170,  remote AS 64829, external link
Description: Peer with  T-bone
  BGP version 4, remote router ID 10.15.253.170
  BGP state  = Established, up for 3d09h
  Last read 00:00:42, hold time is 180, keepalive  interval is 60 seconds
  Neighbor capabilities:
    Route refresh:  advertised and received(old & new)
    Address family IPv4 Unicast:  advertised and received
  Message statistics:
    InQ depth is 0
     OutQ depth is 0
                         Sent       Rcvd
     Opens:                  6          6
    Notifications:          0           0
    Updates:                8         53
    Keepalives:          25270      25270
    Route Refresh:          1          0
     Total:              25285      25329
  Default minimum time between  advertisement runs is 30 seconds

For address family:  IPv4 Unicast
  BGP table version 805489, neighbor version  805489

We are advertising  the 132.5.0.0 to us office and they are advertising the 10.90.0.0 network to us  with the administrative distance of 10.  We are recieving most of the routes  from our bgp peer in us but for some bizarre reason we are still recieving  three routes from ospf (highlighted in red).

   sh  ip route | in 10.90.
B       10.90.91.0/24 [10/3] via 10.15.253.170,  3d09h
B       10.90.112.0/24 [10/20] via 10.15.253.170, 3d09h
B        10.90.113.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.114.0/24 [10/20]  via 10.15.253.170, 3d09h
B       10.90.115.0/24 [10/20] via 10.15.253.170,  3d09h
B       10.90.120.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.102.0/24 [10/20] via 10.15.253.170, 3d09h
B       10.90.106.0/24  [10/20] via 10.15.253.170, 3d09h
B       10.90.107.0/24 [10/3] via  10.15.253.170, 3d09h
B       10.90.108.0/24 [10/20] via 10.15.253.170,  3d09h
B       10.90.109.0/24 [10/20] via 10.15.253.170, 3d09h
B        10.90.110.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.111.0/24 [10/3]  via 10.15.253.170, 3d09h
B       10.90.20.0/23 [10/20] via 10.15.253.170,  3d09h
B       10.90.22.0/23 [10/3] via 10.15.253.170, 3d09h
B        10.90.24.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.25.0/24 [10/3]  via 10.15.253.170, 3d09h
B       10.90.26.0/24 [10/3] via 10.15.253.170,  3d09h
B       10.90.27.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.28.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.30.0/24 [10/3]  via 10.15.253.170, 3d09h
B       10.90.0.0/23 [10/3] via 10.15.253.170,  3d09h
O IA    10.90.0.0/16 [110/254] via 10.254.1.2, 19:54:50,  Vlan719
B       10.90.3.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.4.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.5.0/24 [10/3] via  10.15.253.170, 3d09h
B       10.90.6.0/24 [10/3] via 10.15.253.170,  3d09h
B       10.90.7.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.8.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.50.0/24 [10/20]  via 10.15.253.170, 3d09h
B       10.90.60.0/22 [10/3] via 10.15.253.170,  3d09h
B       10.90.33.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.38.0/24 [10/20] via 10.15.253.170, 3d09h
B       10.90.39.0/24 [10/20]  via 10.15.253.170, 3d09h
B       10.90.40.0/24 [10/20] via 10.15.253.170,  3d09h
O E2    10.90.41.0/24 [110/20] via 10.254.1.2,  19:54:51, Vlan719
O E2    10.90.134.64/26 [110/20] via 10.254.1.2, 19:54:51,  Vlan719
O E2    10.90.243.0/24 [110/20] via 10.254.1.2, 19:54:51,  Vlan719
B       10.90.130.0/24 [10/3] via 10.15.253.170,  3d09h
B       10.90.131.0/24 [10/3] via 10.15.253.170, 3d09h
B        10.90.132.0/24 [10/3] via 10.15.253.170, 3d09h
B       10.90.133.0/24 [10/3]  via 10.15.253.170, 3d09h
B       10.90.135.0/24 [10/3] via 10.15.253.170,  3d09h
B       10.90.140.0/24 [10/3] via 10.15.253.170,  3d09h

We are not quite  sure why the ospf route is being preferred  because the adimin distance is  better from the bgp nei 10.15.253.170 in us. Also

when i do

#sh ip bgp  | in 10.90.
*> 10.90.0.0/23     10.15.253.170            3             0 64829 ?
* i10.90.0.0/16     10.254.2.2             254    100      0 ?
*> 10.90.3.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.4.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.5.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.6.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.7.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.8.0/24     10.15.253.170            3             0 64829 ?
*> 10.90.20.0/23    10.15.253.170           20             0 64829 ?
*> 10.90.22.0/23    10.15.253.170            3             0 64829 ?
*> 10.90.24.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.25.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.26.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.27.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.28.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.30.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.33.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.38.0/24    10.15.253.170           20             0 64829 ?
*> 10.90.39.0/24    10.15.253.170           20             0 64829 ?
*> 10.90.40.0/24    10.15.253.170           20             0 64829 ?
* i10.90.41.0/24    10.254.2.2              20    100      0 ?
*> 10.90.50.0/24    10.15.253.170           20             0 64829 ?
*> 10.90.60.0/22    10.15.253.170            3             0 64829 ?
*> 10.90.91.0/24    10.15.253.170            3             0 64829 ?
*> 10.90.102.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.106.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.107.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.108.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.109.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.110.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.111.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.112.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.113.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.114.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.115.0/24   10.15.253.170           20             0 64829 ?
*> 10.90.120.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.130.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.131.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.132.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.133.0/24   10.15.253.170            3             0 64829 ?
* i10.90.134.64/26  10.254.2.2              20    100      0 ?
*> 10.90.135.0/24   10.15.253.170            3             0 64829 ?
*> 10.90.140.0/24   10.15.253.170            3             0 64829 ?
* i10.90.243.0/24   10.254.2.2              20    100      0 ?

why is this happening and is there work around? 

[Peter Paluch]

Hello Abdul,

All the routes you are complaining about have their IP next hop set to 10.254.1.2. Is it reachable according to your current routing table?

Best regards,

Peter

[abdul.khan]

yes

sh ip route 10.254.1.2
Routing entry for 10.254.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via bgp 65535
  Advertised by bgp 65535
  Routing Descriptor Blocks:
  * directly connected, via Vlan719
      Route metric is 0, traffic share count is 1

its also pingable. The thing is that there are more than those thee routes that are known from 10.254.1.2 but why are these three sticking in the routing table.

thanks

Abdul

[milan.kulik]

Hi,

aren't you redistributing OSPF to BGP on your router?

Can you provide

sh ip bgp 10.90.41.0/24

output?

BR,

Milan

[cadet alain]

Hi,

can you do a
sh ip bgp 10.90.41.0 255.255.255.0
sh ip bgp 10.90.243.0 255.255.255.0
sh ip bgp 10.90.134.64 255.255.255.192

Regards.

alain.

[abdul.khan]

ospf is redistributed into bgp..

yes here are the commands you wanted..

  sh ip bgp 10.90.41.0

BGP routing table entry for 10.90.41.0/24, version 798777
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Multipath: iBGP
  Advertised to non peer-group peers:
  10.15.250.1 10.15.250.2 10.15.255.11
  Local
    10.254.2.2 (metric 101) from 10.15.255.11 (10.15.255.11)
      Origin incomplete, metric 20, localpref 100, valid, internal
  64829, (received & used)
    10.15.253.170 from 10.15.253.170 (10.15.253.170)
      Origin incomplete, metric 20, localpref 100, valid, external
  Local
    10.254.1.2 from 0.0.0.0 (10.15.255.10)
      Origin incomplete, metric 20, localpref 100, weight 32768, valid, sourced

  sh ip bgp 10.90.243.0
BGP routing table entry for 10.90.243.0/24, version 798372
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Multipath: iBGP
  Advertised to non peer-group peers:
  10.15.250.1 10.15.250.2 10.15.255.11
  Local
    10.254.2.2 (metric 101) from 10.15.255.11 (10.15.255.11)
      Origin incomplete, metric 20, localpref 100, valid, internal
  64829, (received & used)
    10.15.253.170 from 10.15.253.170 (10.15.253.170)
      Origin incomplete, metric 20, localpref 100, valid, external
  Local
    10.254.1.2 from 0.0.0.0 (10.15.255.10)
      Origin incomplete, metric 20, localpref 100, weight 32768, valid, sourced, best

#sh ip bgp 10.90.134.64 255.255.255.192
BGP routing table entry for 10.90.134.64/26, version 798376
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Multipath: iBGP
  Advertised to non peer-group peers:
  10.15.250.1 10.15.250.2 10.15.255.11
  Local
    10.254.2.2 (metric 101) from 10.15.255.11 (10.15.255.11)
      Origin incomplete, metric 20, localpref 100, valid, internal
  64829, (received & used)
    10.15.253.170 from 10.15.253.170 (10.15.253.170)
      Origin incomplete, metric 20, localpref 100, valid, external
  Local
    10.254.1.2 from 0.0.0.0 (10.15.255.10)
      Origin incomplete, metric 20, localpref 100, weight 32768, valid, sourced,

[milan.kulik]

Hi,

which means:

You had received the prefix via OSPF first and redistributed that to  BGP.

Even if received from the eBGP neighbor, it would not win, as the 32768 weight would beat the received prefix.

But it seems your eBGP router is not sending the prefix to you, as you had sent your prefix to him first and he realized it had  better BGP attributes (AS_PATH might be the reason) than the same prefixes received from the backbone.

So IMHO, you need to tune your OSPF to BGP redistribution - block the prefixes from redistribution or decrease the weight while redistributed

(see similar recent thread  https://supportforums.cisco.com/message/3298132#3298132).

Don't forget to clear your BGP sessions (soft at least) then.

HTH,

Milan

[Kishore Chennupati]

Milan, I thought the same but you are way quicker than me ;-)

Abdul,

To test this what you can do on your router is to put a filter on your ospf process to stop learning one of the below sunbets via your ospf neighbor and see if you receive it from your eBGP neighbor. If you still dont receive it then I guess you need to check with your eBGP peer whether they are advertising it. But, if you see it in the bgp table then  you could do something what Milan has suggested by reducing the weight to 0 and local pref to 90 or something or maybe nost advertise it back( you dont want to advertise the same network to the peer you learned from)

10.90.41.0 255.255.255.0
10.90.243.0 255.255.255.0
10.90.134.64 255.255.255.192

HTH,

Regards,

Please rate if helpful