---------- Forwarded message ---------- From: Nathan Beard <nbeard@stellarllc.net> Date: Wed, Jun 1, 2016 at 8:25 AM Subject: Route Server #1 - IPv6 To: peering@micemn.net Is there a particular reason why the IPv6 address for route server #1 is no longer reachable following the upgrades that were completed on the night of the 22nd? My IPv6 peering session to the first route server has been stuck in 'Active' state since right around that time and the IPv6 address is also not directly reachable (while route server #2 works fine): // BGP state for route server #1 session // 2001:504:27::d1af:0:1 0 53679 1675496 328107 0 0 0 1w2d Active // Ping to route server #1 // RP/0/RSP0/CPU0:STELLAR-511-ASR9006#ping ipv6 2001:504:27::d1af:0:1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:504:27::d1af:0:1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) // Ping to route server #2 // RP/0/RSP0/CPU0:STELLAR-511-ASR9006#ping ipv6 2001:504:27::d1af:0:2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:504:27::d1af:0:2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms Please let me know when you have an update. Thanks! -- Nathan Beard Network Engineer nbeard@stellarllc.net (218) 820-7636 -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke@neutralpath.net www.neutralpath.net
On Wed, Jun 01, 2016 Nathan Beard <nbeard@stellarllc.net> wrote:
Is there a particular reason why the IPv6 address for route server #1 ..
Hmm, it is reachable for me and 30 others on the exchange. There are two connected to RR#2 via IPv6 that aren't on #1 & you are one of those. RR#2 can ping you, but RR#1 gets nothing back. FWIW: I don't know of your policies, but I can't ping your IPv6 endpoint from my (ie. ipHouse) network either, nor can I connect to your endpoint on the BGP port from RR#1. IPv6 NDP on RR#1 can't seem to resolve you, which is probably why pings and BGP connects don't work. Although I do see BGP traffic sessions coming in from you if I tcpdump, I can't seem to do the neighbor discovery (ie. IPv6 ARP method) to get your address though. 09:05:45.022173 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:47.023930 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:51.025407 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:59.027328 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 But the biggest problem is that RR#1 can't seem to get back to you. Could you check your filters for IPv6, particularly with reguard to ND facing the route servers? There are no filters being run on the RR machines. (ssh et. al filtering is handled upstream). -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
Doug, I had checked my IPv6 ND table prior to submitting my first email, and I still don't see any issues on my side: /RP/0/RSP0/CPU0:STELLAR-511-ASR9006#show ipv6 neighbors te0/1/0/0 | include d1af:0:// //2001:504:27::d1af:0:1 9 0026.b966.2cd8 REACH Te0/1/0/0 0/1/CPU0 // //2001:504:27::d1af:0:2 78 f01f.afdb.a5d5 REACH Te0/1/0/0 0/1/CPU0 / Even with valid ND resolutions I still can only hit the single RR as previously indicated: /RP/0/RSP0/CPU0:STELLAR-511-ASR9006#ping ipv6 2001:504:27::d1af:0:1 // //Type escape sequence to abort.// //Sending 5, 100-byte ICMP Echos to 2001:504:27::d1af:0:1, timeout is 2 seconds:// //.....// //Success rate is 0 percent (0/5)/ /RP/0/RSP0/CPU0:STELLAR-511-ASR9006#ping ipv6 2001:504:27::d1af:0:2// //Type escape sequence to abort.// //Sending 5, 100-byte ICMP Echos to 2001:504:27::d1af:0:2, timeout is 2 seconds:// //!!!!!// //Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms/ I have no IPv6 filtering in place on the interface facing the MICE exchange, and I've verified that I have IPv6 bi-lateral peering sessions up and running to other exchange addresses: /Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd// //2001:504:27::1055:0:1// // 0 4181 19348 19312 9906063 0 0 6d09h 3// //2001:504:27::4e93:0:1// // 0 20115 19371 19313 9906063 0 0 6d09h 19/ Let me know if you have any other suggestions after taking a look, otherwise I'll continue to troubleshoot my side this afternoon. In any case I'm not sure the entire MICE list needs to be copied on this back and forth since it sounds like there are only a couple affected members... Thanks! On 06/01/16 09:17, Doug McIntyre wrote:
On Wed, Jun 01, 2016 Nathan Beard <nbeard@stellarllc.net> wrote:
Is there a particular reason why the IPv6 address for route server #1 ..
Hmm, it is reachable for me and 30 others on the exchange. There are two connected to RR#2 via IPv6 that aren't on #1 & you are one of those.
RR#2 can ping you, but RR#1 gets nothing back.
FWIW: I don't know of your policies, but I can't ping your IPv6 endpoint from my (ie. ipHouse) network either, nor can I connect to your endpoint on the BGP port from RR#1.
IPv6 NDP on RR#1 can't seem to resolve you, which is probably why pings and BGP connects don't work.
Although I do see BGP traffic sessions coming in from you if I tcpdump, I can't seem to do the neighbor discovery (ie. IPv6 ARP method) to get your address though.
09:05:45.022173 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:47.023930 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:51.025407 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0 09:05:59.027328 IP6 2001:504:27::8e16:0:1.36711 > 2001:504:27::d1af:0:1.179: Flags [S], seq 1656210645, win 16384, options [mss 1440,wscale 0,eol], length 0
But the biggest problem is that RR#1 can't seem to get back to you.
Could you check your filters for IPv6, particularly with reguard to ND facing the route servers? There are no filters being run on the RR machines. (ssh et. al filtering is handled upstream).
-- Nathan Beard Network Engineer nbeard@stellarllc.net (218) 820-7636
participants (3)
-
Doug McIntyre -
Jason Hanke -
Nathan Beard