hey,
2000::/6 with aspath 3257 3549 has appeared in global routing table. Surely we can't be only ones seeing it. Looks like someone messed up interface/route config at 3549 by omitting 4 from the prefixlen.
According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
"2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
As of 8h30m EST.
*>i 2000::/6 <ipv6 peer> 100 100 0 3257 3549 i
Last update to IP routing table: 21h23m56s
Hi,
::/24 is also present: AS-PATH 8455 13030 9498 7602
Mailed the tech-c 2 weeks ago, no response so far.
This problem has been solved.
Kind regards,
Job
According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
"2000::/6 is visible by 79% of 92 IPv6 RIS full peers."This problem has been solved.
do we mark it up to pixie dust, or do we get an actual post mortem?
randy
I talked to folks at 3549, they had a few tickets on it that took care of that.
I know we are reviewing our “alloc-boundary” filter to prevent such a large prefix passing again.
- Jared
According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
"2000::/6 is visible by 79% of 92 IPv6 RIS full peers."This problem has been solved.
do we mark it up to pixie dust, or do we get an actual post mortem?
I talked to folks at 3549, they had a few tickets on it that took care
of that.
maybe i am more than usually st00pid this evening, but i am no smarter
on what actually happened, how it was detected/reported by/to someone
who could fix it, and how it was fixed. you know, a basic post mortem,
so some of us could learn a lesson or two.
randy
hey,
maybe i am more than usually st00pid this evening, but i am no smarter
on what actually happened, how it was detected
Dunno about others but I personally detected it using my tools that look for our prefixes (or more specifics) being advertised by someone else. Large covering prefix obviously triggered the bells.
I'm pretty sure it was a typo in the config, the prefix length had to be /64 but was entered as /6 instead.
2000::/64 doesn't make much sense either.
Nick
hey,
2000::/64 doesn't make much sense either.
No and it was obviously not what was configured.
But something like 2001:7d0:1:1::1/64 misconfigured on interface as 2001:7d0:1:1::1/6 becomes 2000::/6
My guess, actually, would be that someone was entering a more specific default (2000::/3) using a numeric keypad and missed the key with an off by one row error.
There is no matching entry in whois for 2000::/64 (or shorter), so it is unlikely that 2000::/64 was an intended configuration.
Owen
hey,
There is no matching entry in whois for 2000::/64 (or shorter), so it is unlikely that 2000::/64 was an intended configuration.
2000::/64 has nothing to do with it.
Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and 23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured prefix length (6 instead 64) becomes 2000::/6 prefix.
It should be rejected for the same reason that 192.168.10.0/16 is
invalid in a prefix list or access list.
Any decent router won't allow you to enter just anything in that range
into the export rules with a /6, except 2000:: itself, and will
even show you a failure response instead of silently ignoring the
invalid input, for the very purpose of helping you avoid such errors.
2001::1/6 would be an example of an invalid input -- there are
one or more non-zero bits listed outside the prefix, or where bits in
the mask are zero.
Only 2000:0000:0000:0000:0000:0000:0000:0000/6 properly conforms,
not just "any IP" in that range can have a /6 appended to the end.
tarko is right in suggesting that config typos can cause this sort of
thing, e.g.
> 2000::/64 has nothing to do with it.
>
> Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and
> 23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured prefix
> length (6 instead 64) becomes 2000::/6 prefix.It should be rejected for the same reason that 192.168.10.0/16 is
invalid in a prefix list or access list.
RTR(config)#ip prefix-list TEST permit 192.168.10.0/16
RTR(config)#do sho ip prefix-list TEST
ip prefix-list TEST: 1 entries
seq 5 permit 192.168.0.0/16
This isn't surprising to people who've been using IOS for a while ...
Any decent router won't allow you to enter just anything in that range
into the export rules with a /6, except 2000:: itself, and will
even show you a failure response instead of silently ignoring the
invalid input, for the very purpose of helping you avoid such errors.
Well, unfortunately, a lot of us have (as you define the term) indecent
routers.
RTR(config)#ipv6 prefix-list TEST permit 2000:1111::/6
RTR(config)#do sho ipv6 prefix-list TEST
ipv6 prefix-list TEST: 1 entries
seq 5 permit 2000::/6
2001::1/6 would be an example of an invalid input -- there are
one or more non-zero bits listed outside the prefix, or where bits in
the mask are zero.Only 2000:0000:0000:0000:0000:0000:0000:0000/6 properly conforms,
not just "any IP" in that range can have a /6 appended to the end.
-- Brett
hey,
Any decent router won't allow you to enter just anything in that range
into the export rules with a /6, except 2000:: itself, and will
even show you a failure response instead of silently ignoring the
invalid input, for the very purpose of helping you avoid such errors.
IOS was already brought up, luckily Junos and TIMOS do just that (both for prefix-lists and static routes). Unfortunately directly connected networks remain and there is no way to solve that.
Which is one of the reasons I think it was more likely a typo for 2000::/3
being entered via numeric keypad.
3 and 6 are adjacent on a numeric keypad and both 2000::/3 and 2000::/6 are
valid prefixes.
Owen