What is a BGP implicit withdraw
When you use the show ip bgp neighbor x.x.x.x command, you get plenty of useful information about BGP peer x.x.x.x.
However I do not understand what an implicit withdraw is -
...
For address family: IPv4 Unicast
BGP table version 6, neighbor version 6/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 1 (Consumes 52 bytes)
Prefixes Total: 0 3
Implicit Withdraw: 0 0
Explicit Withdraw: 0 2
Used as bestpath: n/a 1
Used as multipath: n/a 0
...
The command reference is not particularly enlightening with the following http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp5.html#wp1159860
It says "Number of times that a prefix has been withdrawn and readvertised."
Comments
I found a NANOG presentation (http://is.gd/VMwNBk Page 2) which mentioned that "Implicit" means a former prefix has been replaced. "Explicit" means that a prefix was completly withdrawn and is now no longer in the BGP RIB.
I did a short test in my lab with BB1, BB3, R4 and R6. R4 and R6 are both in AS100 and the backbone routers are in AS54.
Rack1R6#sh bgp ipv4 uni neigh 150.1.4.4 | i Withdr
Implicit Withdraw: 30 30
Explicit Withdraw: 0 0
Route refresh on R4 increases sent implicit withdraw on R6
Rack1R4(config-router)#do clear bgp ipv4 uni 150.1.6.6 soft in
Rack1R6#sh bgp ipv4 uni neigh 150.1.4.4 | i Withdr
Implicit Withdraw: 40 30
Explicit Withdraw: 0 0
Now lets filter 1 prefix completly and do a route refresh again.
hostname Rack1R4
!
ip prefix-list NET_119 seq 5 permit 119.0.0.0/8
!
route-map BGP_POLCIY<BB3 deny 10
match ip address prefix-list NET_119
!
route-map BGP_POLCIY<BB3 permit 20
!
router bgp 100
neighbor 204.12.1.254 route-map BGP_POLCIY<BB3 in
Rack1R4(config-router)# do clear bgp ipv4 uni 204.12.1.254 soft in
Rack1R6#sh bgp ipv4 uni neigh 150.1.4.4 | i Withdr
Implicit Withdraw: 40 30
Explicit Withdraw: 0 1
The counter for received explicitly withdrawn prefixes has increased by 1 now.
is an update to the previously advertised route (i.e. new set of path
attributes).
Good luck with your studies!
Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
[email protected]
Internetwork Expert, Inc.
http://www.INE.com
From: welshydragon
Reply-To: "[email protected]"
Date: Sun, 6 Nov 2011 18:07:47 -0600
To: Brian Dennis
Subject: [CCIE R&S] What is a BGP implicit withdraw
When you use the show ip bgp neighbor x.x.x.x command, you get plenty of
useful information about BGP peer x.x.x.x.
However I do not understand what an implicit withdraw is -
...
For address family: IPv4 Unicast
BGP table version 6, neighbor version 6/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 1 (Consumes 52 bytes)
Prefixes Total: 0 3
Implicit Withdraw: 0 0
Explicit Withdraw: 0 2
Used as bestpath: n/a 1
Used as multipath: n/a 0
...
The command reference is not particularly enlightening with the following
http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp5.
html#wp1159860
It says "Number of times that a prefix has been withdrawn and
readvertised."
INE - The Industry Leader in CCIE Preparation
http://www.INE.com
Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx
Thanks for this!
Thanks Jochen! This article also includes a new BGP capability too :-)
Here was my test
R1
...
hostname R1
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.0 255.255.255.254
!
router bgp 1
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 10.0.0.1 remote-as 2
no auto-summary
...
R2
hostname R2
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.1 255.255.255.254
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.0 remote-as 1
no auto-summary
!
So R1 is advetising prefix 1.1.1.1/32 to R2
I have turned on debug ip bgp updates on R2.
When the session BGP peering first comes up we have -
R2#clear ip bgp *
R2#
%BGP-5-ADJCHANGE: neighbor 10.0.0.0 Down User reset
%BGP-5-ADJCHANGE: neighbor 10.0.0.0 Up
R2#
BGP(0): 10.0.0.0 rcvd UPDATE w/ attr: nexthop 10.0.0.0, origin i, metric 0, path 1
BGP(0): 10.0.0.0 rcvd 1.1.1.1/32
BGP(0): Revise route installing 1 of 1 routes for 1.1.1.1/32 -> 10.0.0.0(main) to main IP table
R2#show ip bgp neighbors 10.0.0.0 | i Withdraw
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
R2#
If I go to R1 and shut Loopback 1 -
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int l1
R1(config-if)#sh
R1(config-if)#
%LINK-5-CHANGED: Interface Loopback1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to down
R1(config-if)#
With the following output on R2 -
R2#
BGP(0): 10.0.0.0 rcv UPDATE about 1.1.1.1/32 -- withdrawn
BGP(0): no valid path for 1.1.1.1/32
BGP(0): nettable_walker 1.1.1.1/32 no best path
R2#show ip bgp neighbors 10.0.0.0 | i Withdraw
Implicit Withdraw: 0 0
Explicit Withdraw: 0 1
R2#
Which generates an explicit withdraw as the prefix is not there anymore!
If we do the following on R1 -
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int l1
R1(config-if)#no sh
R1(config-if)#
%LINK-3-UPDOWN: Interface Loopback1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up
And then do the following on R2 -
R2#clear ip bgp * in
R2#
BGP(0): 10.0.0.0 rcvd UPDATE w/ attr: nexthop 10.0.0.0, origin i, metric 0, path 1
BGP(0): 10.0.0.0 rcvd 1.1.1.1/32...duplicate ignored
R2#show ip bgp neighbors 10.0.0.0 | i Withdraw
Implicit Withdraw: 0 1
Explicit Withdraw: 0 1
R2#
This makes more sense to be now. I guess the debug ending ...duplicate ignored says that this is an update to an exisinting prefix