[c-nsp] Cisco 7600, bgp neighbor default-originate breaks

[Rodney Dunn]

Christian,

For the recreate you have, great job btw, can you get the debugs on the
PE when you do the clear?

Rodney


On Mon, Mar 10, 2008 at 01:10:17PM +0100, Christian Bering wrote:
> Hi all,
> 
> We've seen a couple of incidents where a default originated to some
> customers using "neighbor x.y.z.v default-originate" has suddenly
> stopped working.
> 
> According to documentation and TAC, "neighbor default-originate" is
> unconditional and should always result in a default being advertised to
> the peer.
> 
> TAC has been  unable to reproduce the problem as seen in our production
> network but I have been able to reproduce something very similar in our
> testlab.
> 
> Configuration on PE:
> --------------------
> router bgp 10
>  address-family ipv4 vrf Test
>   no synchronization
>   neighbor 83.136.89.14 remote-as 65002
>   neighbor 83.136.89.14 description CPE3
>   neighbor 83.136.89.14 activate
>   neighbor 83.136.89.14 default-originate
>  exit-address-family
> 
> BGP tabel on CE:
> ----------------
> CPE3#show ip bgp
> BGP table version is 36, local router ID is 83.136.89.14
> 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          83.136.89.13             0             0 10 i
> *> 92.0.0.0/24      83.136.89.13                           0 10 65000 i
> *> 93.0.0.0/24      0.0.0.0                  0         32768 i
> 
> At this point the CE is receiving both a default and a single prefix
> because an outgoing prefix list has not been applied to the PE
> configuration. After applying the following:
> 
> 
> DR2(config)#ip prefix-list default seq 5 permit 0.0.0.0/0
> DR2(config)#router bgp 10
> DR2(config-router)#address-family ipv4 vrf Test
> DR2(config-router-af)#neighbor 83.136.89.14 prefix-list default out
> 
> and doing a soft clear out of the BGP session from the PE, a bgp debug
> on the CE showed the following:
> 
> DR2#clear ip bgp 83.136.89.14 vrf Test soft out      
> 
> CPE3#
> *Jan 31 19:29:26.659: BGP(0): 83.136.89.13 rcvd UPDATE w/ attr: nexthop
> 83.136.89.13, origin i, metric 0, path 10
> *Jan 31 19:29:26.663: BGP(0): 83.136.89.13 rcvd 0.0.0.0/0...duplicate
> ignored
> *Jan 31 19:29:28.139: BGP(0): 83.136.89.13 rcv UPDATE about 0.0.0.0/0 --
> withdrawn
> *Jan 31 19:29:28.139: BGP(0): no valid path for 0.0.0.0/0
> *Jan 31 19:29:28.143: BGP(0): 83.136.89.13 rcv UPDATE about 92.0.0.0/24
> -- withdrawn
> *Jan 31 19:29:28.143: BGP(0): no valid path for 92.0.0.0/24
> *Jan 31 19:29:28.147: BGP(0): 83.136.89.13 rcv UPDATE about 93.0.0.0/24
> -- withdrawn
> *Jan 31 19:29:28.159: BGP(0): nettable_walker 0.0.0.0/0 no best path
> *Jan 31 19:29:28.163: BGP: topo global:IPv4 Unicast:base Remove_fwdroute
> for 0.0.0.0/0
> *Jan 31 19:29:28.167: BGP(0): nettable_walker 92.0.0.0/24 no best path
> *Jan 31 19:29:28.167: BGP: topo global:IPv4 Unicast:base Remove_fwdroute
> for 92.0.0.0/24
> 
> In other words, the default is withdrawn even though it's supposed to be
> there unconditionally.
> 
> The PE confirmed it wasn't sending out a default:
> 
> DR2#show ip bgp vpnv4 vrf Test neigh 83.136.89.14 
> [snip]
>   Default information originate, default not sent
>   Outgoing update prefix filter list is default
> 
> A new soft clear out on the PE resulted in the following:
> 
> DR2#clear ip bgp 83.136.89.14 vrf Test soft out      
> 
> CPE3#
> *Jan 31 19:39:14.719: BGP(0): 83.136.89.13 rcvd UPDATE w/ attr: nexthop
> 83.136.89.13, origin i, metric 0, path 10
> *Jan 31 19:39:14.723: BGP(0): 83.136.89.13 rcvd 0.0.0.0/0
> *Jan 31 19:39:14.727: BGP(0): Revise route installing 1 of 1 routes for
> 0.0.0.0/0 -> 83.136.89.13(global) to main IP table
> 
> The problems in our production network has been seen on software
> releases SRAx and SRBx on the 7600 platform. The above testlab setup was
> on Cisco7200s running 12.2(33)SRC which - I imagine - is similar to SRC
> on the 7600 platform and based on SRA/SRB.
> 
> I know similar problems have been experienced by at least one other
> participant on this list.
> 
> Has anyone else seen these problems?
> 
> -- 
> Regards
>  Christian Bering
>  IP engineer, nianet a/s
>  Phone: (+45) 7020 8730
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/