ipv6 default - ::/3 ?

[Garry Peirce]

Confirmed as a known bug: CSCtx19461
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet
chBugDetails&bugId=CSCtx19461

As I also RX a feed from CYMRU for bogons which contains ::/3 , my reception
of ::/0 was being negatively affected.
One of my instances cleaned up nicely by filtering ::/3 from the bogon feed,
my other instance is being very difficult to clear.

Marcus, it would appear to fit what you were seeing as well -  any ::/X is
mentioned to cause the issue.  
Unfortunately, it looks like SR train will not realize the fix either.  ;-( 

> -----Original Message-----
> From: Marcus Keane [mailto:Marcus.Keane at microsoft.com]
> Sent: Tuesday, November 13, 2012 5:26 PM
> To: peirce at maine.edu; 'Sander Steffann'
> Cc: ipv6-ops at lists.cluenet.de
> Subject: RE: ipv6 default - ::/3 ?
> 
> Hi,
> 
> Just FYI, we saw something similar internally. We introduced ::/1 and
8000::/1
> to get around some problems(don't ask :-)), and from that point, we could
> never get rid of ::/1. It was with 6500s and 12.2(33)SXI*. We could see
with
> debug that the 6500s were definitely receiving ::/0 from the upstream AS,
> but they interpreted it as ::/1 and they also passed on ::/1 to the route-
> reflectors. The only way we could get rid it was to take an outage and
> completely remove the default for a few seconds. We had a TAC case, but in
> discussing with colleagues, we never got a bug ID. However, they did say
the
> fix was being ported to the SXI branch. We didn't pursue it because we
just
> wanted to put in the workaround immediately. I haven't tested, but
> apparently IOS-XR will reject these routes as bogons.
> I know this probably won't be very helpful in your case, but it might be
> interesting.
> Marcus
> 
> -----Original Message-----
> From: ipv6-ops-bounces+mkeane=microsoft.com at lists.cluenet.de
> [mailto:ipv6-ops-bounces+mkeane=microsoft.com at lists.cluenet.de] On
> Behalf Of Garry Peirce
> Sent: Wednesday, 14 November 2012 12:24 AM
> To: 'Sander Steffann'
> Cc: ipv6-ops at lists.cluenet.de
> Subject: RE: ipv6 default - ::/3 ?
> 
> Thanks Sander - that's very interesting.
> 
> However, I've never adjusted the timers and would characterize my config
as
> being quite vanilla.
> Surely there seems something amiss within IOS involving this mutation from
> ::/0 to ::/3.
> Perhaps there is some other function , beyond just timer adjustment, that
> causes this.
> Also to note, enabling soft inbound also shows the ::/3 entry as being
RX'd
> although a bit of debugging shows the ::/0 is coming in.
> I do not know the specific platforms/images running on the peers (yet),
but
> the above seems to tell me it's on my side.
> 
> Sounds like best to open a case - I'll send an update when/if something is
> found.
> 
> 
> 
> > -----Original Message-----
> > From: ipv6-ops-bounces+peirce=maine.edu at lists.cluenet.de [mailto:ipv6-
> > ops-bounces+peirce=maine.edu at lists.cluenet.de] On Behalf Of Sander
> > Steffann
> > Sent: Monday, November 12, 2012 7:20 AM
> > To: peirce at maine.edu
> > Cc: ipv6-ops at lists.cluenet.de
> > Subject: Re: ipv6 default - ::/3 ?
> >
> > Hi Garry,
> >
> > > I've been seeing an odd v6 situation and wondered if any may be
> > > seeing
> > the same.
> > >
> > > I have two different v6 providers originating a default v6 (expected
> > > to
> be
> > ::/0) into two different routers of mine.
> > > I'm not seeing it from either ;  however my routers tell me I am
> > > RX'ing
> a ::/3
> > from each which I believe is a bogon.
> > > They claim they are default-originating a ::/0  , are not
> > > advertising a
> ::/3   ,
> > nor do they have this prefix in their tables.
> > >
> > > As it looks oddly similar to 2000::/3, I'm curious if it's being
> > > mucked
> with
> > within IOS when received.
> > > I'm seeing this on Cisco76xx under SRE6,7 & 7a.
> > > I've tried removing filtering/routemaps with no change in behavior.
> I've
> > not had an opportunity to sniff it.
> > >
> > > Outside of the aspect of accepting/using a default, anyone else
> > > seeing
> this
> > or know why it may be?
> >
> > This is a bug that I ran into earlier this year. It happens when you
> > set
> the BGP
> > timers to a low value on the receiving router. Here is an example.
> > This is before setting the timers:
> >
> > > router1#sh bgp ipv6 unicast neighbors 2001:DB8:810:1::1
> > > received-routes BGP table version is 1, local router ID is 10.0.56.5
> > > Status codes: s suppressed, d damped, h history, * valid, > best, i
> > > -
> internal,
> > >              r RIB-failure, S Stale, m multipath, b backup-path, x
> > > best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? -
> > > incomplete
> > >
> > >   Network          Next Hop            Metric LocPrf Weight Path
> > > *  ::/0             2001:DB8:810:1::1
> > >                                             0             0 65531 i
> > >
> > > Total number of prefixes 1
> >
> > Then I change the timers:
> >
> > > router1#conf t
> > > Enter configuration commands, one per line.  End with CNTL/Z.
> > > router1(config)#router bgp 65530
> > > router1(config-router)#neighbor 2001:DB8:810:1::1 timers 10 30
> >
> > Now clear the session and look again:
> >
> > > router1(config-router)#do clear bgp ipv6 unicast 2001:DB8:810:1::1
> > > router1(config-router)#do sh bgp ipv6 unicast neighbors
> > > 2001:DB8:810:1::1 received-routes BGP table version is 54339, local
> > > router ID is 10.0.56.5 Status codes: s suppressed, d damped, h
> > > history,
> *
> > valid, > best, i - internal,
> > >              r RIB-failure, S Stale, m multipath, b backup-path, x
> > > best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? -
> > > incomplete
> > >
> > >   Network          Next Hop            Metric LocPrf Weight Path
> > > *  ::/3             2001:DB8:810:1::1
> > >                                             0             0 65531 i
> > >
> > > Total number of prefixes 1
> > > router1(config-router)#
> >
> > And suddenly we have the ::/3 route. The very annoying thing is that
> > it doesn't disappear when removing the timers:
> >
> > > router1(config-router)#no neighbor 2001:DB8:810:1::1 timers 10 30
> > > router1(config-router)#do clear bgp ipv6 unicast 2001:DB8:810:1::1
> > > router1(config-router)#do sh bgp ipv6 unicast neighbors
> > > 2001:DB8:810:1::1 received-routes BGP table version is 54339, local
> > > router ID is 10.0.56.5 Status codes: s suppressed, d damped, h
> > > history,
> *
> > valid, > best, i - internal,
> > >             r RIB-failure, S Stale, m multipath, b backup-path, x
> > > best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? -
> > > incomplete
> > >
> > >  Network          Next Hop            Metric LocPrf Weight Path
> > > *  ::/3             2001:DB8:810:1::1
> > >                                            0             0 65531 i
> > >
> > > Total number of prefixes 1
> > > router1(config-router)#
> >
> > Only reloading the box after removing the timers fixes this...
> >
> > This was tested on a test-box without a active support contact so I
> couldn't
> > create a TAC case for it, but I did report it to people inside Cisco.
> > The firmware was an 15.1XB* release from lisp.cisco.com from around
> > April. I don't know the exact XB release anymore though :-(
> >
> > - Sander
>