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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
