[AusNOG] Not quite routing issue

[Marcus Emanuel]

Not that it should matter but the only difference I can see is that your new range has no reverse DNS associated with it.

1.20.20.103.in-addr.arpa (103.20.20.1)

Vs

103.232.216.1

Not sure if anyone would put traffic policies in place against 'naked' IP's like this but just stood out during that quick LG trace.

What does a trace to Facebook look like for you?

Marcus.

From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Marcus Emanuel
Sent: Monday, 22 September 2014 6:11 PM
To: Michael J. Carmody; ausnog at ausnog.net
Subject: Re: [AusNOG] Not quite routing issue

Hi Michael,

Interesting Observation below

A trace from http://lg.he.net/ (using their own default freemont pop, or any others I pick in the US) give these results:

On an IP from original /24, three packets give response at all hops including 103.20.20.1 on your network.

On an IP from new Range, 2/3 Packets fail to get a response to 103.232.216.1

It would be interesting to get a device with both an old and new IP on your network with the same default GW and using the same firewall policy and hitting them both the same way.

No breakthrough here for you sorry mate, but just another perspective that makes this more interesting.

Marcus.



From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Michael J. Carmody
Sent: Monday, 22 September 2014 4:19 PM
To: ausnog at ausnog.net<mailto:ausnog at ausnog.net>
Subject: [AusNOG] Not quite routing issue

Hey All,

With the recent allotment of another APNIC subnet to our company, we have been beating our head against an issue which has us stumped.

In short a client on a layer-2 service cannot reach Facebook, Seek, ADP Payroll portal and a bunch of other websites intermittently, but more often not, than can...

When we move them to our original  subnet range (same router, same layer 2 service, same client CPE) all is well.

We original suspected a routing issue, but pings/traceroutes work. Then we expected a MSS/MTU issue, but clamping all the way down to 1300 made no difference.

We then got weird and noticed we could get a response from the loadbalancer/CDN/proxy of facebook, asking for a nonsense URL, but if we asked for a valid URL we get no reply.

So we seem to have an issue affecting Facebook, seek.com.au and ADP payroll, that is not routing related (can ping/traceroute without an issue), not MTU related, (can clamp up and down without any affect), but somehow related to the IP range of CDN fronted services?

103.20.20.x/24 works for us and all our clients.
103.232.216.x/23 seems to work mostly with sporadic sites not loading.

Same router, same upstream peer, same everything else...

Can someone point out where our stupidity lies? We are very stumped here.

-Michael Carmody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140922/d67cc3b3/attachment.html>