BGP Local policy Denied Prefixes

[tsalt]

I have an IP-VPN BGP network. I have a CE router and PE router running eBGP.

On teh CE router I have some static routes configured that are not appearing on the PE router, although the CE router says it is advertising them.

Looking at the PE router BGP information I can see that some routes are being denied because of a "NEXT_HOP non-local: .

Please could some one advise why this could occur.

I have tried both a redistribute static and a network statement configured on teh CE router and neither works.

BGP state = Established, up for 3d21h

Last read 00:00:32, hold time is 180, keepalive interval is 60 seconds

Neighbor capabilities:

Route refresh: advertised and received(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: 12983 59

Keepalives: 267182 267214

Route Refresh: 0 0

Total: 280171 267279

Default minimum time between advertisement runs is 30 seconds

For address family: VPNv4 Unicast

Translates address family IPv4 Unicast for VRF ISOFT_VRF1

BGP table version 6624748, neighbor version 6624748/0

Output queue sizes : 0 self, 0 replicated

Index 28, Offset 3, Mask 0x10

Member of update-group 28

Site-of-Origin is SoO:64563:200

Overrides the neighbor AS with my AS before sending updates

Inbound path policy configured

Route map for incoming advertisements is ISOFT_Manchester_SOO

Sent Rcvd

Prefix activity: ---- ----

Prefixes Current: 88 5 (Consumes 320 bytes)

Prefixes Total: 266 5

Implicit Withdraw: 34 0

Explicit Withdraw: 144 0

Used as bestpath: n/a 4

Used as multipath: n/a 0

Outbound Inbound

Local Policy Denied Prefixes: -------- -------

Suppressed duplicate: 7 0

NEXT_HOP non-local: n/a 12

SOO loop: 10 n/a

Total: 17 12

Maximum prefixes allowed 500

Threshold for warning message 80%

Number of NLRIs in the update sent: max 0, min 0

Connections established 6; dropped 5

Last reset 3d21h, due to Peer closed the session

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 172.31.36.65, Local port: 27771

Foreign host: 172.31.36.66, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x3BB8CAE04):

Timer Starts Wakeups Next

Retrans 5962 0 0x0

TimeWait 0 0 0x0

AckHold 5664 5488 0x0

SendWnd 0 0 0x0

KeepAlive 0 0 0x0

GiveUp 0 0 0x0

PmtuAger 0 0 0x0

DeadWait 0 0 0x0

iss: 454154180 snduna: 454274846 sndnxt: 454274846 sndwnd: 15880

irs: 3313196430 rcvnxt: 3313304506 rcvwnd: 15182 delrcvwnd: 1202

SRTT: 305 ms, RTTO: 697 ms, RTV: 43 ms, KRTT: 0 ms

minRTT: 0 ms, maxRTT: 544 ms, ACK hold: 200 ms

Flags: higher precedence, nagle, md5

Datagrams (max data segment is 1440 bytes):

Rcvd: 11644 (out of order: 0), with data: 5664, total data bytes: 108075

Sent: 11563 (retransmit: 0, fastretransmit: 0), with data: 5961, total data bytes: 120665

Many Thanks

Tom

[Harold Ritter]

The NEXT_HOP non-local counter is normally incremented when a path is received from a directly connected eBGP peer (non-multihop) and that the BGP next-hop attribute for that path is not part of the directly connected subnet.

Do you by any chance modify the next-hop on the CE using a route-map?

What version of IOS are you using?

Thanks,

[tsalt]

We are not modifying the next hop on the CE router.

The revision of IOS is 12.2(6i) and the router is a 7200 series router.

[Harold Ritter]

Could you also tell me what ios image you are using on the CE and post the relevant PE BGP configuration for the BGP session with the CE.

Thanks,

[tsalt]

address-family ipv4 vrf cust_VRF1

redistribute connected

neighbor *.*.36.66 remote-as 64563

neighbor *.*.36.66 password

neighbor *.*.36.66 activate

neighbor *.*.36.66 as-override

neighbor *.*.36.66 route-map cust_Manchester_SOO in

neighbor *.*.36.66 maximum-prefix 500 80

route-map cust_Manchester_SOO permit 10

match ip address ntlvpn_cust_Manchester_SOO-10

set extcommunity soo 64563:200

!

ip access-list standard ntlvpn_cust_Manchester_SOO-10

permit any

CE IOS:-

c7200-is-mz.122-6i.bin

PE Neighbor output

BGP neighbor is *.*.36.66, vrf cust_VRF1, remote AS 64563, external link

BGP version 4, remote router ID *.*.39.53

BGP state = Established, up for 2d22h

Last read 00:00:34, hold time is 180, keepalive interval is 60 seconds

Neighbor capabilities:

Route refresh: advertised and received(new)

Address family IPv4 Unicast: advertised and received

Message statistics:

InQ depth is 0

OutQ depth is 0

Sent Rcvd

Opens: 7 7

Notifications: 0 0

Updates: 13672 64

Keepalives: 282875 282908

Route Refresh: 0 0

Total: 296554 282979

Default minimum time between advertisement runs is 30 seconds

For address family: VPNv4 Unicast

Translates address family IPv4 Unicast for VRF cust_VRF1

BGP table version 7949860, neighbor version 7949860/0

Output queue sizes : 0 self, 0 replicated

Index 28, Offset 3, Mask 0x10

Member of update-group 28

Site-of-Origin is SoO:64563:200

Overrides the neighbor AS with my AS before sending updates

Inbound path policy configured

Route map for incoming advertisements is cust_Manchester_SOO

Sent Rcvd

Prefix activity: ---- ----

Prefixes Current: 103 5 (Consumes 320 bytes)

Prefixes Total: 214 5

Implicit Withdraw: 15 0

Explicit Withdraw: 96 0

Used as bestpath: n/a 4

Used as multipath: n/a 0

Outbound Inbound

Local Policy Denied Prefixes: -------- -------

Suppressed duplicate: 6 0

NEXT_HOP non-local: n/a 8

SOO loop: 12 n/a

Total: 18 8

Maximum prefixes allowed 500

Threshold for warning message 80%

Number of NLRIs in the update sent: max 0, min 0

Connections established 7; dropped 6

Last reset 2d22h, due to Peer closed the session

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 172.31.36.65, Local port: 29926

Foreign host: 172.31.36.66, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x3F3987B4C):

Timer Starts Wakeups Next

Retrans 4450 0 0x0

TimeWait 0 0 0x0

AckHold 4257 4124 0x0

SendWnd 0 0 0x0

KeepAlive 0 0 0x0

GiveUp 0 0 0x0

PmtuAger 0 0 0x0

DeadWait 0 0 0x0

iss: 3089292530 snduna: 3089382481 sndnxt: 3089382481 sndwnd: 16203

irs: 1735209700 rcvnxt: 1735290866 rcvwnd: 16080 delrcvwnd: 304

SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms

minRTT: 0 ms, maxRTT: 392 ms, ACK hold: 200 ms

Flags: higher precedence, nagle, md5

Datagrams (max data segment is 1440 bytes):

Rcvd: 8719 (out of order: 0), with data: 4257, total data bytes: 81165

Sent: 8655 (retransmit: 0, fastretransmit: 0), with data: 4449, total data bytes: 89950

[Harold Ritter]

It looks like the next-hop received from the CE is not the directly connected address. I have seen a few bugs similar to that in the past.

Just to confirm, is it possible for you the run the following debug command on the PE for the specific peer:

debug ip bgp *.*.36.66 updates

Hope this helps,

[tsalt]

Many Thanks.

Do you have the bug IDs of teh bugs you have seen before?

I did think this and we are going to do this when we can get an outage from the customer.

I will update when I have done this.

[Harold Ritter]

Could you post the CE BGP configuration so I try to match the behavior you are seeing to an actual DDTS.

Thanks,

[tsalt]

Thanks. Sorry for the delay. Below is the CE BGP config:-

router bgp 64563

no synchronization

bgp log-neighbor-changes

network 10.1.10.0 mask 255.255.254.0

network 10.1.111.0 mask 255.255.255.0

network 10.200.10.0 mask 255.255.255.0

network 192.168.48.0 mask 255.255.248.0

network 0.0.0.0

redistribute static

neighbor 172.*.*.* remote-as 4445

neighbor 172.*.*.* password

no auto-summary

[Harold Ritter]

I couldn't find one specific bug that relates to the configuration you have.

I would definitely upgrade since 12.2(6i) is kind of old.

It would be interesting to find-out what is the next-hop received on the PE. Have you had time to run the debug command suggested in a previous posting?

One more thing. I see you have a "network 0.0.0.0" statement in the CE config. What is the source for this route. Would it be possible to use the "neighbor x.x.x.x default-originate" command instead and see whether the issue is still present.

Thanks,