[bcop] BCOP presentation at RIPE meeting in Warsaw

[now with IPv6 WG address in cc:, actually]

On 15/05/14 00:57, Jen Linkova wrote:
> Hi Jan,
>
> finally I've managed to summarize my comments to the doc ;)

Hi,

thank you very much for all your comments. I'm bringing part of this 
discussion to IPv6 WG mailing list as it is of technical nature and I 
think it belongs here.

I put all your comments in our issues tracker, reachable publicly at
https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues

> 1) You suggest to have a local mirror of the test-ipv6. While it
> definitely makes sense, using the local mirror might hide some edge
> connectivity issues so it worth mentioning. We might recommend to use
> *both*.

Yes, absolutely. This diversity would also help the ISP to understand if 
he has any IPv6 issues in other parts of the network other than access ;)

>
> 2) Section 5
> You provide detailed instruction on how to run ping, but then saying
> just 'check DNS settings' and even 'configure different servers' -
> support engineers who need explanations on ping, would need more
> detailed explanations on how to change DNS settings.
>
> "If IPv4 is working but the page is unavaliable' - I'd assume that an
> engineer could not tell if 'IPv4 is working'. So IMHO we shall just
> say that if site is unreachange - troubleshoot as any other 'I can not
> open this page' v4-only case.
> If we believe that troubleshooting such case is in scope of this
> document, I'd suggest to include traceroute as a troubleshooting step.

seems as a good idea. let us think about that ;)

>
> 3) Helpdesk code section:
> I'd use different fonts/color to distinguish between 'fixed' and
> 'example' fields in the output.
>
> 4) Code 112 (v4 + broken Ipv6)
>
> - can we show the process as a flowchart? if-then-else?

that's a bit hard one... do we have anybody specialized in flowcharts here?

> For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if
> it is not,, the customer either has a misconfigured CPE (which has
> IPv6 enables while it should not), or there is other Ipv6-enabled
> device which is used as a router. Check CPE configuration/state for
> IPv6 and disable it if it has it enabled'.
>
> - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the
> customer and you manage their CPE, check if CPE has a approved
> firmware version. Upgrade it if it does not'.
>
> - I'd say that grep (to find the IPv6 address on MacOS) should be
> 'grep -E "en|inet6" so interface name is visible (to avoid the scnario
> when addresses are assigned to wrong interface);
>
> - the IPv6 addresses table is a little bit confusing:
>    -- it contains 6to4 case which should not cause code 112 (as well as
> Teredo case);
>    -- some sections say 'call theor router vendor for support'. I
> believe we shall clarify somewhere in the beginning of the document
> that we assume that the support deals with customers CPE and if it is
> not a case, those CPE-related instructions should be either 'escalate'
> or 'advise customer to contact their router vendor for support' (which
> in my reality would never happen.....:)
>   -- as each section of the tabel has instructions (and the last row
> says 'escalate', it is not clear in which case the engieer should
> proceed to the next step (checking the home router config).
>
> the section of home router config check is a little bit confusing.
> When we just say 'check the configuration of the device', it does not
> mean much as we don't specify what we are looking for. Maybe we shall
> say smth like:
>   - 'if CPE is managed by your support, check if CPE is configured as
> per your internal documentation' (as we might say somewhere in the doc
> that in that case it is strongly recommended to have a separate how-to
> on what should be configured on those CPEs);
>   - check if the LAN interface has IPv6 address from the ISP allocated range;
>   - check on user device if it has routers's both link-local (fe80:...)
> and ISP-assigned address in the neighbor discovery cache (<provide
> commands);
>   - check the routing table on the user's device; see if the default
> route points to the router's address. If not - check if DHCP and or
> RAs are enabled on the home router.
>   - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops.

I think this are all good suggestions. We'll go through them during our 
authosr edit cycle meeting, probably during the IETF meeting in Toronto.

>
>
> Code 46 Section
> - I'd sugegst to run traceroute to see where it stops. If traceroute
> does not show any issues - escalate. If it does outside of your
> network - contact the affected netwokr NOC.

ack...

>
>
> IMHO a section should be added which explains what kind of information
> should be collected for an escalation. I'd suggest:
>   - Ipv4 and Ipv6 traceroute;
>   - ifconfig output
>   - routing table output
>   - maybe packet capture for the session which is having issues.

I think this is asking a bit too much to a first level helpdesk 
employee... I don't know...

Cheers, Jan