[c-nsp] Cisco 7600, bgp neighbor default-originate breaks
Christian Bering
CB at nianet.dk
Mon Mar 10 08:10:17 EDT 2008
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
More information about the cisco-nsp
mailing list