BGP Not advertising routes

[mumbles202]

I was trying to troubleshoot a BGP issue where the peer isn't receiving some of the routes I'm like to advertise.  I can get the actual configuration, but this is basically what I have and what I'm trying to accomplish:

int gi 0/0

 IP address A.B.D.1 255.255.255.224

 description WAN Public IPs

int g0/1

 IP address 1.1.1.1 255.255.255.252

 description Uplink to ISP

ip route A.B.C.32 255.255.255.224 192.168.10.1

ip route E.F.G.0 255.255.255.0 192.168.10.1

ip route A.B.C.92 255.255.255.248 192.168.10.2

ip route A.B.C.0 255.255.255.0 Null0 250

router bgp 12345

 router-id A.B.C.1

 bgp log-neighbor-changes

 neighbor 1.1.1.2 remote-as 6789

address-family ipv4

 neighbor 1.1.1.2 activate

 network A.B.C.0 mask 255.255.255.0

 network A.B.D.0 mask 255.255.255.0

 network E.F.G.0 mask 255.255.255.0

A.B.C.0 and A.B.D.0 are adjoining (192.168.58.0 and 192.168.59.0) and the carrier advised they have a prefix-list applied to only accept routes A.B.C.0/23 and E.F.G.0 from my router.  They're getting the E.F.G.0/24 advertisement w/o any issues, but the A.B.C.0/24 and A.B.D.0/24 don't get advertised.  I've tried using more specific network statements and clearing the bgp session but had the same results.  I'll get the output of a "sh ip bgp neighbors 1.1.1.2 advertised-routes" tomorrow but wondering if there is something else I missed.  I tried using a prefix-list and matching the 2 /24 networks but that didn't work either.

[mumbles202]

Since weight/local preference were the same I was thinking R2 was using R1s default route since it has a shorter AS Path. To get around that i had tried prepend the AS a couple of times so that R1's advertised default route would have a AS Path of 3333 3333 3333, but that didn't seem to work as when i issued a show ip bgp the AS path was still 3333.

route-map IN_PREPEND permit 10
  set as-path prepend last-as 3

R1(config-route-map)#router bgp 12345
R1(config-router)# address-family ipv4
R1(config-router-af)# neighbor 10.0.0.2 route-map IN_PREPEND in

In terms of the iBGP/eBGP and local preference, you're saying because the local preference was 150 on R2, R1 will choose to prefer the iBGP route w/ a metric of 200 regardless of the eBGP route?  If that's the case I understand the reason why the OSPF route would be installed as R1 has a static 0.0.0.0/0 route pointing to an interface w/ a metric of 200 which would explain the rib failure on the BGP route.

[Jon Marshall]

Correct re your last paragraph, that is why the OSPF route is chosen. 

You could use weight because that is local to the router ie. it is not passed between routers so apply weight to the default route that R2 receives from it's ISP peer which would mean R1 uses it's default, R2 uses it's default but they would still send the IBGP routes to each other.

Jon

[mumbles202]

Using the weight attribute worked perfectly in the lab so I'll be updating that in production soon.  I did have 1 question that was discovered during testing:  

When we were testing that internet access was available through both R1 and R2 we noticed that if we did things in this order we had an outage.  Disconnected R1 from it's upstream provider; it then learned it's route via OSPF from R2 as expected and routed out that connection.  Trace route and looking up connections on BGP looking glasses showed traffic going through R2 ISP.  But then when we reconnected R1 to it's upstream and it began learning the default route and sending traffic out that way.  Trace routes seemed to indicate the correct path. 

When we then disconnected R2 from it's upstream we expected traffic to fail back to R1.  R2 did in fact have a default route of R1, but pings to the internet failed.  Looking on BGP looking glasses and the networks that should have been advertised out of R1 were still showing as available from R2's ISP for quite some time.  We plugged R2 back in after a few minutes as there was no internet available for anyone in the building.  That restored service and some time later when i checked the looking glasses I was able to see the path had gone back over to the carrier for R1. 

Shouldn't the route update from R1 to its ISP have been pushed out fairly quickly. R1 is advertising a /24 and R2 a /23 as well. 

[Muhammad Awais Khan]

Good to hear that weight parameter worked out with you. How much time approx it took to come back? 

[Georg Pauwen]

Hello,

can you post the output of:

show ip bgp neighbors 1.1.1.2 advertised-routes