<div dir="ltr">Dear Brian<div><br></div><div><br></div><div>I don't have routing issues with those IPs. ICMP is working perfactly fine and hence server is reachable. </div><div><br></div><div><div><font size="1" face="monospace, monospace">anurag@server7:~$ ping -c 5 103.9.185.229</font></div><div><font size="1" face="monospace, monospace">PING 103.9.185.229 (103.9.185.229) 56(84) bytes of data.</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.229">103.9.185.229</a>: icmp_seq=1 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.229">103.9.185.229</a>: icmp_seq=2 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.229">103.9.185.229</a>: icmp_seq=3 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.229">103.9.185.229</a>: icmp_seq=4 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.229">103.9.185.229</a>: icmp_seq=5 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace">--- 103.9.185.229 ping statistics ---</font></div><div><font size="1" face="monospace, monospace">5 packets transmitted, 5 received, 0% packet loss, time 4007ms</font></div><div><font size="1" face="monospace, monospace">rtt min/avg/max/mdev = 209.578/209.646/209.734/0.056 ms</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace">anurag@server7:~$ ping -c 5 103.9.185.230</font></div><div><font size="1" face="monospace, monospace">PING 103.9.185.230 (103.9.185.230) 56(84) bytes of data.</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.230">103.9.185.230</a>: icmp_seq=1 ttl=55 time=210 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.230">103.9.185.230</a>: icmp_seq=2 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.230">103.9.185.230</a>: icmp_seq=3 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.230">103.9.185.230</a>: icmp_seq=4 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace">64 bytes from <a href="http://103.9.185.230">103.9.185.230</a>: icmp_seq=5 ttl=55 time=209 ms</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace">--- 103.9.185.230 ping statistics ---</font></div><div><font size="1" face="monospace, monospace">5 packets transmitted, 5 received, 0% packet loss, time 4002ms</font></div><div><font size="1" face="monospace, monospace">rtt min/avg/max/mdev = 209.460/209.721/210.021/0.459 ms</font></div><div><font size="1" face="monospace, monospace">anurag@server7:~$</font></div></div><div><br></div><div><br></div><div>But yes, I agree both servers should be on different subnets for avoiding possible filtering or routing issue in one (though that isn't case here). </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 24, 2015 at 1:11 AM, Brian Candler <span dir="ltr"><<a href="mailto:brian@nsrc.org" target="_blank">brian@nsrc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 23/12/2015 18:04, Anurag Bhatia
wrote:<br>
</div>
<blockquote type="cite">
<div>I tried querying <a href="http://ns1.btraccl.net" target="_blank">ns1.btraccl.net</a>.
(103.9.185.229) and <a href="http://ns2.btraccl.net" target="_blank">ns2.btraccl.net</a>.
(103.9.185.230) on both UDP and TCP port 53 and it's failing. </div>
<div><br>
</div>
</blockquote></span>
But it does work from other parts of the Internet. e.g. from the UK
(on 3 Mobile network):<span class=""><br>
<br>
$ dig @<a href="http://103.9.185.229" target="_blank">103.9.185.229</a> <a href="http://btraccl.net" target="_blank">btraccl.net</a> ns<br>
<br></span>
; <<>> DiG 9.8.3-P1 <<>> @<a href="http://103.9.185.229" target="_blank">103.9.185.229</a>
<a href="http://btraccl.net" target="_blank">btraccl.net</a> ns<span class=""><br>
; (1 server found)<br>
;; global options: +cmd<br></span>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
43131<br>
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2<span class=""><br>
;; WARNING: recursion requested but not available<br>
<br>
;; QUESTION SECTION:<br></span>
;<a href="http://btraccl.net" target="_blank">btraccl.net</a>. IN NS<br>
<br>
;; ANSWER SECTION:<br>
<a href="http://btraccl.net" target="_blank">btraccl.net</a>. 86400 IN NS <a href="http://ns1.btraccl.net" target="_blank">ns1.btraccl.net</a>.<br>
<a href="http://btraccl.net" target="_blank">btraccl.net</a>. 86400 IN NS <a href="http://ns2.btraccl.net" target="_blank">ns2.btraccl.net</a>.<br>
<br>
;; ADDITIONAL SECTION:<br>
<a href="http://ns1.btraccl.net" target="_blank">ns1.btraccl.net</a>. 14400 IN A 103.9.185.229<span class=""><br>
<a href="http://ns2.btraccl.net" target="_blank">ns2.btraccl.net</a>. 14400 IN A 103.9.185.230<br>
<br></span>
So there is a partial/intermittent routing problem for this subnet.
But this is why RFC 2182 says you must different nameservers on
different backbones; then a partial loss of connectivity is not
disastrous.<br>
<br>
The routing problem should of course also be looked at (although if
you fix it, it doesn't absolve you from getting an offsite secondary
:-)<br>
<br>
<a href="http://bgp.he.net/ip/103.9.185.229" target="_blank">http://bgp.he.net/ip/103.9.185.229</a><br>
<br>
Interesting: there's an announcement of the whole /8, and an
announcement of the /22, from two different ISPs. Is it possible
that some providers are filtering out the /22 ?<br>
<br>
Furthermore, I see no entry in the APNIC database for the /22:<br>
<br>
$ whois -h <a href="http://whois.apnic.net" target="_blank">whois.apnic.net</a> <a href="http://103.9.184.0/22" target="_blank">103.9.184.0/22</a><br>
% [<a href="http://whois.apnic.net" target="_blank">whois.apnic.net</a>]<br>
% Whois data copyright terms
<a href="http://www.apnic.net/db/dbcopyright.html" target="_blank">http://www.apnic.net/db/dbcopyright.html</a><br>
<br>
% Information related to '103.0.0.0 - 103.255.255.255'<br>
<br>
inetnum: 103.0.0.0 - 103.255.255.255<br>
netname: APNIC-AP<br>
descr: Asia Pacific Network Information Centre<br>
descr: Regional Internet Registry for the Asia-Pacific
Region<br>
descr: 6 Cordelia Street<br>
descr: PO Box 3646<br>
descr: South Brisbane, QLD 4101<br>
descr: Australia<br>
country: AU<br>
admin-c: HM20-AP<br>
tech-c: NO4-AP<br>
mnt-by: APNIC-HM<br>
mnt-lower: APNIC-HM<br>
mnt-irt: IRT-APNIC-AP<br>
status: ALLOCATED PORTABLE<br>
changed: <a href="mailto:hm-changed@apnic.net" target="_blank">hm-changed@apnic.net</a> 20110204<br>
source: APNIC<br>
<br>
But there *is* an entry in RADB:<br>
<br>
$ whois -h <a href="http://whois.radb.net" target="_blank">whois.radb.net</a> <a href="http://103.9.184.0/22" target="_blank">103.9.184.0/22</a><br>
route: <a href="http://103.9.184.0/22" target="_blank">103.9.184.0/22</a><br>
descr: Equitel Communications Ltd.-Route Object<br>
origin: AS58616<br>
admin-c: Ahsan Habib<br>
tech-c: Rashedul Islam<br>
notify: <a href="mailto:support@equitel.com.bd" target="_blank">support@equitel.com.bd</a><br>
mnt-by: MAINT-AS45273<br>
changed: <a href="mailto:rashedul.islam@btraccl.com" target="_blank">rashedul.islam@btraccl.com</a> 20130829 #05:36:05Z<br>
source: RADB<br>
<br>
The thing to do is to test from those parts of the Internet where
it's not working: traceroute to 103.9.185.229 from those places, and
also traceroute back to those places from 103.9.185.229. If
possible, ask the upstreams to look for the route in their BGP
feeds.<br>
<br>
It could of course be that Equitel has problems with outbound
routing to certain parts of the Internet. The way to prove this one
way or another is with tcpdump or query logs.<br>
<br>
Say the remote host is x.x.x.x; then on your nameserver
103.9.185.229 run<br>
<br>
tcpdump -i eth0 -nn -s0 -v host x.x.x.x and udp port 53<br>
<br>
Then on the remote host issue "dig @<a href="http://103.9.185.229" target="_blank">103.9.185.229</a> <a href="http://btraccl.net" target="_blank">btraccl.net</a> mx".
Does the query arrive at 103.9.185.229? Does 103.9.185.229 send a
reply? (tcpdump will answer those two questions).<br>
<br>
This is all just generic network debugging.<br>
<br>
Regards,<br>
<br>
Brian.<br>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif"><br></font></div><div><br></div><font face="arial, helvetica, sans-serif">Anurag Bhatia<br></font><div></div><div><font face="arial, helvetica, sans-serif"><a href="http://anuragbhatia.com" target="_blank">anuragbhatia.com</a></font><div><br></div></div><div><font face="arial, helvetica, sans-serif"><a><br></a></font></div><div>PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2</div></div></div></div></div>
</div>