Nexus BGP debug

[Ratheesh mv]

I have run conditional debug on nexus box but not getting proper out .No information of filtered subnet in the debug out.

We want to prove that subnet is being advertised from our end with necessary modification.(As override etc...). 

Post Conditional debug configuration I have cleared BGP peer as soft out to regenerate updates. 

Conditional debug configuration

-----------------------

debug-filter bgp neighbor 192.168.10.2

debug-filter bgp prefix 10.35.82.136/32

debug bgp updates

debug logfile bgpdebug.log

Debug output

===========

show debug logfile bgpdebug.log
2021 Feb 17 02:32:51.952372 bgp: [29452] (default) UPD: [IPv4 Unicast] Continuing update run for pee
r 192.168.10.2 (#0)
2021 Feb 17 02:32:51.952437 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1
, Origin: Incomplete
2021 Feb 17 02:32:51.952468 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 2, length 1
0, AS-Path: <6500 6500>
2021 Feb 17 02:32:51.952485 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 3, length 4
, Next-hop: 10.254.110.233
2021 Feb 17 02:32:51.952500 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 4, length 4
, Med: 0
2021 Feb 17 02:32:51.952531 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1
, Origin: Incomplete
2021 Feb 17 02:32:51.952547 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 2, length 1
0, AS-Path: <6500 6500>
2021 Feb 17 02:32:51.952561 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 3, length 4
, Next-hop: 10.254.110.233
2021 Feb 17 02:32:51.952574 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 4, length 4
, Med: 0
2021 Feb 17 02:32:51.952596 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1
, Origin: Incomplete
2021 Feb 17 02:32:51.952611 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 2, length 1
0, AS-Path: <6500 6500>
2021 Feb 17 02:32:51.952625 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 3, length 4
, Next-hop: 192.168.10.2
2021 Feb 17 02:32:51.952638 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 4, length 4
, Med: 0
2021 Feb 17 02:32:51.952659 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1, Origin: Incomplete
2021 Feb 17 02:32:51.952675 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 2, length 10, AS-Path: <6500 6500>
2021 Feb 17 02:32:51.952689 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 3, length 4, Next-hop: 192.168.10.2
2021 Feb 17 02:32:51.952702 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 4, length 4, Med: 0
2021 Feb 17 02:32:51.952725 bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1, Origin: Incomplete

[balaji.bandi]

bgp: [29452] (default) UPD: 192.168.10.2 Sending attr code 1, length 1, Origin: Incomplete

You need to find the reason, why it failed, it hard to say, for now, we need to know more information. is this learned from IGP? are you doing redistribution?

you can use the below command to see any failure in the RIB

#sh ip bgp rib-failure

[linuxheels]

Also something else to try and or consider is to make sure there isn't a prefix list tied to a route map configured in your BGP config outbound that is preventing the ip from being advertised out. I've been burned by this with inbound routes from a customer in which they updated some of their addresses in the scope and didn't provide them to us and we had a prefix list for what routes to accept in and those weren't on there. Something to check and hope it helps.