JANOG34_Meeting/Meeting_Report/SUMMARY - JANOG - JApan Network Operators Group

The purpose of JANOG, which stands for JApan Network Operators' Group, is the discussion and review of technical and operational topics surrounding the Internet. JANOG's activities are a mailing list and semiannual meetings for on-site discussion and sharing of information.

At JANOG 34, there were 547 attendees, which is the largest besides the previous meetings in Tokyo, so the presentations and discussions were very excited and hot like the midsummer heat. :-)

In addition to the standard JANOG program, a routing tutorial and BoF meetings covering 7 topics also were held as co-located meetings the day before JANOG 34 meeting.

Introduction of JANOG 34 programs

JANOG 34 had a theme "Mix and Shuffle", and consisted of programs from a wide variety of fields based on this theme.

The topics at JANOG 34 included network events visualisation and full route table operation in content service providers, as well as network operation sessions, NTP/DNS reflection attack in the security session, and considerations about the white box switch as the current trend session.

You can see the abstracts about the programs in JANOG 34.

"Let's talk about IP anycast"

In this program report, we briefly introduce "Let's talk about IP anycast" presented by Yoshinobu Matsuzaki from IIJ. It was a typical program in JANOG meeting.

IP anycast is a well known technology on the server side. The benefit of it is that the closest server always responds to client requests. It is commonly used for DNS and other applications though, the network design, operation and troubleshooting of it is troublesome in some cases. In this presentation, we were sharing pros/cons about IP anycast and discussing operational considerations.

Since IP anycast is a useful technology depending on how you use it, it's use will increase. For further operational improvements of IP anycast, we had a discussion on recovery in the event of a service outage.

As a recovery method, we can delete routes to the effected server. Deleting the routes can be achieved by shutting down the interface on your routers or shutting down the BGP neighbour if you using BGP routing.

In case that multiple services are run by a server on a prefix, what options are available for deleting routes to the server? This is one of the main issues for operators.

Two options were suggested in JANOG 34 discussion.

One is deleting the route to the server to take bypass healthy services as well as faulty services. This option requires the distribution of anycast instances when any troubles happens. Another is continuing operation without deleting route to the server. This option requires the way to recover the service at the application level.

IP anycast was discussed through a perspective of the service availability in JANOG 34 meeting.

(Naohide Kamitani, FURUKAWA NETWORK SOLUTION CORP.)

Discussions on IP anycast

Q: Question from attendee
A: Answer or comment from speaker
C: Comment from attendee

C: We use IP anycast as a gateway of a service. The same IP address is used for both Osaka and Tokyo for disaster planning. This is possible as being stateless.

Q: We use IP anycast for DNS referral of internal servers. I'm more interested to hear inputs from the floor on how to delete its route at the time of failure, rather than route propagation.
A: We do neighbour shutdown when using interface shutdown or BGP.
C: We don't delete the route. We have several real physical servers behind LB, so it wouldn't go down unless datacenter breaks. Would like to know if there are good solutions for deleting the route.

Q: We use anycast for cash DNS referals. Many operational headaches. Where is it being accessed, its impact at the time of failures, etc. Additionally, behaviors are different for real IP address and IP used for any case. It's an issue we don't have the answer yet, as we don't know where to look into when wanting to see the behavior of IP address for anycast. Would be interested to hear, if there is a good solution.
A: When deploying anycast instance, there is an approach to deploy monitoring server or hosts which is able to access remotely at the same time.

C: Have been operating anycast for over 10 years and observe different behaviors for UDP anycast and TCP anycast. It's no problem dropping UDP packets but it's quite troublesome to re-send if TCP packets are dropped.

C: Used to deploy 6to4. Would like to share its experience at the time. Both src and dst will be anycast in 6to4, which makes trouble shooting difficult. For example, is hard to trace whether it is due to src or dst that the packet is lost, or causing strange routing behavior.

Q: When the same prefix is used in multiple services, wouldn't they all get effected rather than the service with trouble, if you delete the route at the time of failure.
A: Very difficult issue. Either to shut all services including the ones which are working, or leave the service which has failed as it is. If you shut other services as well, it is desirable to make sure anycast instances are well distributed. If you leave the service with failure as it is, you need to come up with other approaches, such as trouble shooting at the application level.

Q: I had used a service using anycast in the past. I have made a query at the time of service failure, to share the IP address of the physical server. Was that not appropriate?
A: Would expect not wanting to share it, as could be a target of attacks, or possibly used in multiple managements.

C: AMT (Automatic Multicast Tunnel) is an example of a protocol which uses anycast. Perhaps use ATM for stable service.

C: RIPE Atlas could perhaps be used as a tool.