[bcop] BCOP presentation at RIPE meeting in Warsaw
- Previous message (by thread): [bcop] BCOP presentation at RIPE meeting in Warsaw
- Next message (by thread): [bcop] BCOP presentation at RIPE meeting in Warsaw
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Zorz @ go6.si
jan at go6.si
Thu May 22 11:35:25 CEST 2014
[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
- Previous message (by thread): [bcop] BCOP presentation at RIPE meeting in Warsaw
- Next message (by thread): [bcop] BCOP presentation at RIPE meeting in Warsaw
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ BCOP Archives ]