For everyone interested, this got id CSCue96950 Bug Details Outgoing Interface for IPv6 BGP Routes Became Unknown
Symptom: IPv6 routes pointing to *unknown* interface after interface flapping, disturbing the traffic forwarding and requires hard reset of BGP session: RP/0/RP0/CPU0:CISCO#show route ipv6 bgp Mon Mar 4 16:13:45.458 CET B 2001:600::/32 [200/0] via fe80::d2d0:fdff:fe0d:9979, 00:01:05, Unknown Conditions: "bgp fast-external-fallover disable" is configured and IPv6 BGP Session is up and Fast deletion and reconfiguration of an interface. Workaround: 1- Enable "bgp fast-external-fallover" or 2- Reset BGP session -- Tassos Tassos Chatzithomaoglou wrote on 30/1/2013 21:51: > tbh, this is something i didn't even think about...and i don't know why they > chose to go > with /48. > > https://www.peeringdb.com/private/exchange_view.php?id=347 > > > PS: sorry for the previous "pgp" email. > > > -- > Tassos > > > Gert Doering wrote on 30/1/2013 21:09: >> Hi, >> >> On Wed, Jan 30, 2013 at 08:57:25PM +0200, Tassos Chatzithomaoglou wrote: >>> Yes, that's the LAN of the local IX. >>> >>> interface TenGigE0/2/0/3.290851 >>> description ** GRIX ** >>> ipv4 address x.x.x.x/24 >>> ipv6 address 2001:648:2100::x/48 >> This... is amazing. And then people complain that a /64 is too big for >> a single LAN. >> >> I'd expect more bugs and unexpected behaviour - implementations get tested >> with "LAN = /64", and sometimes with "/112" or "/124", but I'd expect >> most interesting results for connected networks with shorter masks. >> >> gert _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
