Re: 2000::/6
On Sep 14, 2014, at 2:19 PM, Jimmy Hess mysi...@gmail.com wrote: On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan ta...@lanparty.ee wrote: 2000::/64 has nothing to do with it. Any address between 2000::::::: and 23ff::::::: 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:::::::/6properly 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
Re: 2000::/6
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
Re: 2000::/6
On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan ta...@lanparty.ee wrote: 2000::/64 has nothing to do with it. Any address between 2000::::::: and 23ff::::::: 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:::::::/6properly conforms, not just any IP in that range can have a /6 appended to the end. -- -JH
Re: 2000::/6
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 6
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
Re: 2000::/6
On Sun, Sep 14, 2014 at 04:19:42PM -0500, Jimmy Hess wrote: On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan ta...@lanparty.ee wrote: 2000::/64 has nothing to do with it. Any address between 2000::::::: and 23ff::::::: 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:::/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:::::::/6properly conforms, not just any IP in that range can have a /6 appended to the end. -- Brett
Re: 2000::/6
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::::::: and 23ff::::::: together with misconfigured prefix length (6 instead 64) becomes 2000::/6 prefix. -- tarko
Re: 2000::/6
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
Re: 2000::/6
On 12/09/2014 08:53, Tarko Tikan wrote: 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
Re: 2000::/6
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 -- tarko
Re: 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 On Sep 12, 2014, at 12:53 AM, Tarko Tikan ta...@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
Re: 2000::/6
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
Re: 2000::/6
On Sep 11, 2014, at 9:24 AM, Randy Bush ra...@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
Re: 2000::/6
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
Re: 2000::/6
As of 8h30m EST. *i 2000::/6 ipv6 peer1001000 3257 3549 i Last update to IP routing table: 21h23m56s - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 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.
Re: 2000::/6
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 aheb...@pubnix.net wrote: As of 8h30m EST. *i 2000::/6 ipv6 peer1001000 3257 3549 i Last update to IP routing table: 21h23m56s - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 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 w...@null0.nl
Re: 2000::/6
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
