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." -- tarko
As of 8h30m EST. *>i 2000::/6 <ipv6 peer> 100 100 0 3257 3549 i Last update to IP routing table: 21h23m56s ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 09/10/14 07:20, Tarko Tikan wrote:
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."
Hi, ::/24 is also present: AS-PATH 8455 13030 9498 7602 Mailed the tech-c 2 weeks ago, no response so far. On 10 September 2014 14:33, Alain Hebert <ahebert@pubnix.net> wrote:
As of 8h30m EST.
*>i 2000::/6 <ipv6 peer> 100 100 0 3257 3549 i Last update to IP routing table: 21h23m56s
----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 09/10/14 07:20, Tarko Tikan wrote:
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."
-- Wouter Prins wp@null0.nl
On Wed, Sep 10, 2014 at 02:20:45PM +0300, Tarko Tikan wrote:
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."
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
On Sep 11, 2014, at 9:24 AM, Randy Bush <randy@psg.com> wrote:
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. 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. -- tarko
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 On Sep 12, 2014, at 12:53 AM, Tarko Tikan <tarko@lanparty.ee> wrote:
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.
-- tarko
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. -- tarko
On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko@lanparty.ee> wrote:
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. -- -JH
On 14/09/2014 22:19, Jimmy Hess wrote:
Any decent router won't allow you to enter just anything in that range into the export rules with a /6, except 2000:: itself
tarko is right in suggesting that config typos can cause this sort of thing, e.g. -- router bgp 65555 address-family ipv6 redistribute static ipv6 route 2001:418:3ef:1000::/6 2001:db8::1 -- Bear in mind that the "network" statement in the router bgp stanza on cisco routers is only one of several methods of injecting prefixes into a bgp rib, and is a method that many people routinely avoid because it means duplication of configuration: each network statement requires a grounding "ip{v6} route" statement in order to work stably. So why not combine the two? Nick
On Sun, Sep 14, 2014 at 04:19:42PM -0500, Jimmy Hess wrote:
On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko@lanparty.ee> wrote:
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. -- tarko
On Sep 14, 2014, at 2:19 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko@lanparty.ee> wrote:
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.
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
participants (10)
-
Alain Hebert -
Brett Frankenberger -
Jared Mauch -
Jimmy Hess -
Job Snijders -
Nick Hilliard -
Owen DeLong -
Randy Bush -
Tarko Tikan -
Wouter Prins