OpenDNS

[#1]

I know some people here use OpenDNS for IPV4 but they now also offer IPV6 too!
http://www.opendns.com/ipv6/
If you're able to have an alternative in case HE has issues then it'll be good, or maybe you just want a change!  Any idea when PN's going to have IPV6 DNS servers? Their IPV4 servers seem to resolve the names (see traceroute below) but are not IPV6.

Cisco877W#traceroute ipv6.google.com
Translating "ipv6.google.com"...domain server (212.159.13.49) [OK]
Type escape sequence to abort.
Tracing the route to ipv6.l.google.com (2A00:1450:400C:C01::6A)
  1 2A02:16C8:0:1::4 44 msec 52 msec 44 msec
  2 2A02:16C8:1:8006::1 44 msec 48 msec 44 msec
  3 2A02:16C8:1:8016::1 44 msec 48 msec 48 msec
  4 2001:4860:1:1:0:1AD7:: 48 msec 44 msec 44 msec
  5 2001:4860::1:0:15F 48 msec
    2001:4860::1:0:3067 48 msec 96 msec
  6 2001:4860::8:0:2DDE 45 msec
    2001:4860::8:0:2DDF 48 msec 44 msec
  7 2001:4860::8:0:2AC4 72 msec 52 msec
    2001:4860::8:0:2AC3 52 msec
  8 2001:4860::2:0:87D 52 msec
    2001:4860::2:0:87B 48 msec 52 msec
  9 2001:4860:0:1::22F 60 msec 60 msec 52 msec
 10 ipv6.l.google.com (2A00:1450:400C:C01::6A) 56 msec 48 msec 56 msec

Also, maybe someone can explain why hop 5, 6, 7 and 7 all have 2 hops in them that don't count as a hop?

[#2]

Hi David,
They are not two hops as such, but rather reflections of the fact that successive pings do not necessarily take the same path through the network thus for any given hop count (TTL value) you might see responses from different routers/interfaces where multiple paths exist. Traceroute is just telling you where/who the response came from.
Mathew

[#3]

Another alternative DNS: 2001:4860:4860::8888 and/or 2001:4860:4860::8844 (Google)

[#4]

Another quick question about DNS.  Currently my DNS looks a little like:

ip name-server 212.159.13.49
ip name-server 212.159.13.50
ip name-server 208.67.222.222
ip name-server 2001:470:20::2
ip inspect tcp reassembly queue length 1024
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool ipv6pool
 dns-server 2620:0:CCC::2
 dns-server 2001:470:20::2

I have ip name-server 2001:470:20::2 because later on in the config it complains about not being able to find 2001:...  Oddly, when I put one in...

Cisco877W#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cisco877W(config)#ip name-server ?
  A.B.C.D     Domain server IP address (maximum of 6)
  X:X:X:X::X  Domain server IPv6 address (maximum of 6)
  vrf         Specify VRF
Cisco877W(config)#ip name-server

It says "Max of 6" when in reality it's a max of 4...

Cisco877W(config)#ip name-server 8.8.8.8
% Name-server table is full; 8.8.8.8 not added

So in reality it's a maximum of 4 (ignore the dns-server IP's as for some reason they are not counted).  So my question is, where should I put the DNS servers in my config?  Should I really have 4 IPV4's under ip name-server and then put the IPV6 as dns-server?  I still get IPV6 DNS without an IPV6 in ip name-server so it's kind of confusing as to where to actually keep my DNS settings, though I wonder what the limit actually is there?

[#5]

Quote from: David

I have ip name-server 2001:470:20::2 because later on in the config it complains about not being able to find 2001:...

What do you mean by this?

Quote

So my question is, where should I put the DNS servers in my config?  Should I really have 4 IPV4's under ip name-server and then put the IPV6 as dns-server?

It is important to recognise the difference between the ip name-server and dns-server commands. The ip name-server command is used purely by the router itself i.e. if it ever needs to perform a DNS lookup (e.g. for a ping/traceroute/ssh-connection/etc) then that's the server(s) it'll use. The addresses you specify here are not ever communicated to clients. The servers entered by the dns-server command on the other hand are communicated to clients i.e. offered to them as part of their DHCP configuration. It would therefore be entirely normal to see the same set of DNS servers specified in both command lists.
Does that help?
Mathew

[#6]

Quote from: MJN

Quote from: David I have ip name-server 2001:470:20::2 because later on in the config it complains about not being able to find 2001:... What do you mean by this?

It goes like:

Cisco877W#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cisco877W(config)#no ip name-server 2001:470:20::2
Cisco877W(config)#int Dialer0
Cisco877W(config-if)#ipv6 dhcp client pd pnipv6 rapid-commit
% Nameserver entry 2001:470:20::2 does not exist
Cisco877W(config-if)#

When I remove the entry from ip name-server the dhcp client complains it doesn't exist (which is fair enough, it doesn't!), though how it knows 2001: doesn't exist when it doesn't exist is probably a paradox.
I think I understand now, having another look at my config clarified it a little bit.  For IPV4 I have dns-server as 192.168.0.1 so it uses itself and pulls the addresses from ip name-server, so if my ip name-server was blank it'd never be able to find any addresses on the router front.  Now I'm wondering if I should have the dns-server on the IPV4 pool pointing to proper dns servers like PlusNet, OpenDNS or/and Google.
I have found a horrible bug with IOS though, 15.0 works perfectly except I can't get IPV6 on BVI so no wireless IPV6, not a bug in itself but to get that I need to go to 15.1 which made a change somewhere that causes my internet connection to drop and won't bring it back up until I issue a reload command, it only happens when lots of connections are made so things like bittorrent or updating FFXIV will cause my internet to go down so I'm going to have to figure out what's different between the 15.0 config and 15.1 that is causing the issue.  Google seems to point to "ip virtual-reassembly in" which in 15.0 is "ip virtual-reassembly" without the in/out.  They never make things simple.

[#7]

Quote from: David

% Nameserver entry 2001:470:20::2 does not exist

I haven't seen that error before, and cannot understand why it could be side-stepped by adding the entry. Just to get to the bottom of it (given that it's no problem having 2001:40:20::2 listed under ip name-server) you could try removing the ip-nameserver entry, clearing your DHCP binding with clear ipv6 dhcp client dialer 0, and then re-entering the ipv6 dhcp client pd pnipv6 command (without rapid-commit tag to force a full-on DHCPv6 handshake) - see if that still baulks.
It may actually be the case that when the DHCPv6 process renews it is attempting to remove the dynamically-assigned 2001:470:20::2 address (as a runtime variable, not from the config) but the act of you manually doing it beforehand (from the config, which in turn removes it as a runtime variable) is causing the error to be thrown. Perhaps if you were to shut dialer 0 down first you might not fall into the same trap as you won't be 'working on the engine whilst still running' as it were.

Quote

When I remove the entry from ip name-server the dhcp client complains it doesn't exist (which is fair enough, it doesn't!), though how it knows 2001: doesn't exist when it doesn't exist is probably a paradox.

Plusnet dish out the address as part of the DHCPv6 options list - see sh ipv6 dhcp int dial 0 (and/or debug ipv6 dhcp detail prior to a clear ipv6 dhcp client dialer 0. It should not have to be specified in your ip name-server list though - that's the whole point.

Quote

For IPV4 I have dns-server as 192.168.0.1 so it uses itself and pulls the addresses from ip name-server, so if my ip name-server was blank it'd never be able to find any addresses on the router front.

Remember the dns-server addresses are only used by clients so, yes, if the router didn't have an ip name-server listed then lookups for both itself and clients would fail.

Quote

Now I'm wondering if I should have the dns-server on the IPV4 pool pointing to proper dns servers like PlusNet, OpenDNS or/and Google.

I would. I don't see any real advantage with listing 192.168.0.1 - there's little to be gained, but potentially something to be lost (performance) by having all queries handled by the router rather than just passed through. In fact, I didn't even know that Cisco routers could act as recursive resolvers for clients.

Quote

I'm going to have to figure out what's different between the 15.0 config and 15.1 that is causing the issue.  Google seems to point to "ip virtual-reassembly in" which in 15.0 is "ip virtual-reassembly" without the in/out.

You could just try disabling virtual-reassembly throughout - perhaps it's handling of it is buggy in 15.1 (or was turned off by default in 15.0).

Quote

They never make things simple.

Of course, you/we wouldn't appreciate it quite so much then when it's all working!
Mathew

[#8]

Quote from: MJN

Plusnet dish out the address as part of the DHCPv6 options list - see sh ipv6 dhcp int dial 0 (and/or debug ipv6 dhcp detail prior to a clear ipv6 dhcp client dialer 0. It should not have to be specified in your ip name-server list though - that's the whole point.

DNS is handled by HE isn't it as PN don't have their own IPV6 DNS server up and running?

Quote

You could just try disabling virtual-reassembly throughout - perhaps it's handling of it is buggy in 15.1 (or was turned off by default in 15.0).

I had a feeling it was something to do with "ip inspect tcp reassembly" being too low, so I've removed that and changed it to a zone based thing:

parameter-map type ooo global
tcp reassembly alarm off
tcp reassembly memory limit 4096
tcp reassembly queue length 64
tcp reassembly timeout 5

Hopefully that (by quadrupling the settings) may solve the issue as when I was dc'ing my syslog showed out of order errors, if that doesn't work then not sure, can I really just disable virtual reassembly without any issues?

Quote

Of course, you/we wouldn't appreciate it quite so much then when it's all working!

hehehe, till it breaks again

[#9]

Quote from: David

DNS is handled by HE isn't it as PN don't have their own IPV6 DNS server up and running?

That's right, but in the absence of having their own IPv6-enabled DNS server(s) they are handing out the address of one of HE's to clients instead.

Quote

if that doesn't work then not sure, can I really just disable virtual reassembly without any issues?

Virtual reassembly is a DOS-prevention mechanism. The risk is that an attacker might bombard your firewall with fragments of packets in the knowledge that the firewall will likely want to hold on to the all the fragments until it can combine them into one packet for proper inspection - this takes resources and can overwhelm the firewall if the packets never get completed. The router can help out by taking some of the load and buffering all these fragments, but only for a limited amount of time (and other tweakable parameters) - if the fragments to make a complete packet do not all arrive in time then it simply drops the lot thus saving the firewall the hassle of dealing with what could well be dodgy fragments. The 'virtual' aspect is because it does not actually combine the fragments into a single packet - it merely buffers them and sends them on once content that they will form a full packet. There's no real harm in disabling this feature altogether, unless you are at risk of a DOS attack! (Ironically though, it sounds like implementation of this very feature is causing a DOS itself!)
Mathew

[#10]

It didn't work.  I turned on logging which didn't show Dialer0 dropping (thought it would do that), what it shows before it bugs out:

<188>189: 000234: Sep 12 12:38:50.347 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1022557145 1500 bytes is out-of-order; expected seq:1022526485. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:38:51.386	
<188>190: 000235: Sep 12 12:39:05.650 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1029731585 1500 bytes is out-of-order; expected seq:1029705305. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:39:06.689	
<190>191: 000236: Sep 12 12:39:18.637 PCTime: %FW-6-DROP_PKT: Dropping tcp session 94.249.185.20:39747 81.174.168.169:22 on zone-pair ccp-zp-out-self class class-default due to  DROP action found in policy-map with ip ident 0 	192.168.0.1	12/09 13:39:19.675	
<188>192: 000237: Sep 12 12:39:31.324 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1044889305 1500 bytes is out-of-order; expected seq:1044861565. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:39:32.364	
<188>193: 000238: Sep 12 12:39:50.917 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1049768625 1500 bytes is out-of-order; expected seq:1049740885. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:39:51.956	
<188>194: 000239: Sep 12 12:40:20.975 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1067382065 1500 bytes is out-of-order; expected seq:1067355785. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:40:22.015	
<188>195: 000240: Sep 12 12:40:48.494 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1074025065 1500 bytes is out-of-order; expected seq:1074000245. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:40:49.534	
<190>196: 000241: Sep 12 12:41:52.784 PCTime: %FW-6-DROP_PKT: Dropping icmpv6 session [FE80::90:1A00:5A3:8D26]:0 [FF02::1]:0 on zone-pair ccp-zp-out-self class class-default due to  DROP action found in policy-map with ip ident 0 	192.168.0.1	12/09 13:41:53.824	
<188>197: 000242: Sep 12 12:42:07.355 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1078629905 1500 bytes is out-of-order; expected seq:1078605085. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:42:08.396	
<188>198: 000243: Sep 12 12:43:25.957 PCTime: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1086944605 1500 bytes is out-of-order; expected seq:1086919785. Reason: TCP reassembly queue overflow - session 192.168.0.7:61661 to 66.180.192.254:80 on zone-pair 	192.168.0.1	12/09 13:43:26.997	
<190>199: 000244: Sep 12 12:44:06.967 PCTime: %FW-6-DROP_PKT: Dropping icmpv6 session [FE80::90:1A00:5A3:8D26]:0 [FF02::1]:0 on zone-pair ccp-zp-out-self class class-default due to  DROP action found in policy-map with ip ident 0 	192.168.0.1	12/09 13:44:08.008

That looks a bit messy, but yeah, I get a fair few of those "Dropping TCP Segment" and then Dialer0 goes dead, I can issue a clear int atm0.1 and it'll bring Dialer0 back up, but no traffic goes through and then the connection dies again, only way to fix it is to issue a reload, it's quite annoying.

[#11]

Your tcp reassembly queue length needs increasing - that's what the queue overflow message are indicating. All said and done however, if it's causing issues then I'd just disable reassembly altogether.
Mathew

[#12]

I disabled the virtual one (which is the only thing I can find) I changed it to "no ip virtual-reassembly in" on int dialer0 and BVI1, pretty much got me in the head scratching stages, I should buy a book!