Solved: Problems with BGP routes advertisement

lcuchisanmillan · ‎09-17-2010

Hi all,

We have a router with two interfaces connected to the sames ISPs router, running BGP in both interfaces:

     Serial0/0/0:0               10.11.8.106              YES      NVRAM       down                  down
     ATM0/1/0.1                 10.11.9.106          YES      NVRAM         up                    up
     Loopback1                  192.168.24.148       YES      NVRAM       up                    up

We want to configure all the traffic through Serial 0/0/0 and use ATM0/1/0.1 as backup, for that we have configured the following in BGP:

router bgp 64512
no synchronization
bgp log-neighbor-changes
network 10.11.8.104 mask 255.255.255.252
network 10.11.9.104 mask 255.255.255.252
network 10.11.73.0 mask 255.255.255.0
network 192.168.24.148 mask 255.255.255.255
neighbor 10.11.8.105 remote-as 12338
neighbor 10.11.9.105 remote-as 12338
neighbor 10.11.9.105 route-map OUT in
neighbor 10.11.9.105 route-map Back out
distance bgp 50 50 50
no auto-summary
!

!
route-map BACK permit 10
set as-path prepend 64512 64512
!
route-map OUT permit 10
set local-preference 90
!

For BGP neighbor 10.11.9.105 we try to receive the routes that it announces with local preference 90 and we try to announce our routes with prepend 64512 64512 so always 10.11.8.105 will have the best paths.

Now we are in a situation that neighbour 10.11.8.105 is down.

In our router we are receiving routes OK from 10.11.9.105, but the problem is that we do not see any routes advertised to 10.11.9.105:

sh ip bgp ne 10.11.8.105 routes

Total number of prefixes 0

sh ip bgp ne 10.11.8.105 advertised-routes

Total number of prefixes 0

sh ip bgp ne 10.11.9.105 advertised-routes

Total number of prefixes 0

sh ip bgp ne 10.11.9.105 routes
BGP table version is 1529, local router ID is 192.168.24.148
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.11.9.105                    90      0 12338 12338 ?
*> 10.0.0.0/24      10.11.9.105                    90      0 12338 12338 ?
*> 10.3.0.0/24      10.11.9.105                    90      0 12338 12338 ?
*> 10.7.254.0/24    10.11.9.105                    90      0 12338 12338 ?
*> 10.11.0.0/24     10.11.9.105                    90      0 12338 12338 ?
*> 10.11.1.0/24     10.11.9.105                    90      0 12338 12338 ?
*> 10.11.1.10/32    10.11.9.105                    90      0 12338 12338 ?
*> 10.11.2.0/24     10.11.9.105                    90      0 12338 12338 ?

sh ip route | i C
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
C 192.168.24.148 is directly connected, Loopback1
C 10.11.9.104/30 is directly connected, ATM0/1/0.1

Any ideas where the problem could be?

Thank you

milan.kulik · ‎09-20-2010

Hi,

IMHO, the problem could be:

neighbor 10.11.9.105 route-map Back out
distance bgp 50 50 50
no auto-summary
!

route-map BACK permit 10
set as-path prepend 64512 64512
!

As route-map names are case sensitive in IOS, you are referring to a non-existing route-map in your

neighbor 10.11.9.105 route-map Back out

command.

As a result, no prefixes are being advertised to your neighbor.

HTH,

Milan

View solution in original post

Giuseppe Larosa · ‎09-17-2010

Hello,

the only network that could be sent is :

network 10.11.73.0 mask 255.255.255.0

the other two are:

one is the link with eBGP peer

the other one is the other link that is likely down

the show ip route connected shows that net 10.11.73.0/24 is not a connected route

check with

sh ip route 10.11.73.0

if the route exists in the IP routing table of the node

in other words if you add

router bgp 64512

network 192.168.24.148 mask 255.255.255.255

this route should be sent being alive.

Hope to help

Giuseppe

lcuchisanmillan · ‎09-19-2010

Thank you for your answer Giuslar,

I understand that network 10.11.73.0 is not been anounced because is down and it is not in the routing table, but I do not quite understand why you say networks 192.168.24.148/32 and 10.11.9.104/30 should not be advertised, our intention is to do that:

router bgp 64512
no synchronization
bgp log-neighbor-changes
network 10.11.8.104 mask 255.255.255.252
network 10.11.9.104 mask 255.255.255.252
network 10.11.73.0 mask 255.255.255.0
network 192.168.24.148 mask 255.255.255.255

and both networks are up and as you can see both networks are in the routing table

Serial0/0/0:0 10.11.8.106 YES NVRAM down down
ATM0/1/0.1 10.11.9.106 YES NVRAM up up

Loopback1 192.168.24.148 YES NVRAM up up

sh ip route | i C
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
C 192.168.24.148 is directly connected, Loopback1
C 10.11.9.104/30 is directly connected, ATM0/1/0.1

Thank you

Giuseppe Larosa · ‎09-19-2010

Hello Lcuchisnamillan,

I beg your pardon I had missed the network command covering the loopback's IP subnet.

About the connected IP subnet, the advertisement should not be seen on receiver side as it is a connected route on it with lower AD but I agree it should be advertised by the node with the network command.

Clearly the other network, that of the loopback should be advertised and received

Have you tried what happens without the applied route-maps?

Hope to help

Giuseppe

milan.kulik · ‎09-20-2010

Hi,

IMHO, the problem could be:

neighbor 10.11.9.105 route-map Back out
distance bgp 50 50 50
no auto-summary
!

route-map BACK permit 10
set as-path prepend 64512 64512
!

As route-map names are case sensitive in IOS, you are referring to a non-existing route-map in your

neighbor 10.11.9.105 route-map Back out

command.

As a result, no prefixes are being advertised to your neighbor.

HTH,

Milan

lcuchisanmillan · ‎09-20-2010

Thank you very much milan,

The problem was there i did not pay attention to the name of the route-map

Thank you again

Peter Paluch · ‎09-20-2010

Milan,

Good eye! I was going over it a couple of times and didn't see it... I guess I have to buy a larger monitor

Best regards,

Peter