[bcop] BCOP presentation at RIPE meeting in Warsaw

Hi Jan,

finally I've managed to summarize my comments to the doc ;)

0) the document says that the target audience is residential ISPs and
enterprise IT helpdesk while most of troubleshooting steps are mostly
applicable for residential ISPs as they imply that there are CPE/home
devices/etc. Shall we create another doc for enterprise networks or
just extend this one?

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*.

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.

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?
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.


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.


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.

On Thu, Apr 10, 2014 at 12:41 PM, Jan Zorz @ go6.si <jan at go6.si> wrote:
> Dear BCOP group,
>
> I would like to get a short slot in BCOP TF meeting in Warsaw, I would like
> to present the 00 version of a draft "IPv6 troubleshooting for helpdesks"
>
> The 00 draft can be found in PDF format here:
>
> http://go6.si/ipv6-troubleshooting-for-helpdesks/ (find the link at the end
> of the text).
>
> I would encourage you to read the text and comment in terms if this is
> something that could be the best current operational practice - and
> particularly I'm searching for people that would join the working pack and
> continue the technical IPv6 part in IPv6 WG, where we would like to check
> for IPv6 technical validity and soundness of the document.
>
> Thank you very much, Jan Zorz
>



-- 
SY, Jen Linkova aka Furry