<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style></style></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1>[This email has also gone to the EIX-WG ]<o:p> </o:p>Bad traffic is coming into my IX Peering interface.<o:p></o:p>How do I find out where that bad traffic is coming from?<o:p></o:p>How do I get it to stop?<o:p></o:p><o:p> </o:p>Customers of Internet Exchanges get a good deal on peering. Life is easy. Until something goes wrong.<o:p></o:p>DDoS traffic starts coming into the IX interface…. <o:p></o:p><o:p> </o:p>I work for Arbor Networks and I have seen such questions many times.<o:p></o:p>cFlow, Netflow, IPFIX can show that there is anomalous traffic arriving, but not where it is coming from (last hop).<o:p></o:p>I have a suggestion and I would like to know if it is already in use, or considered of any use….<o:p></o:p><o:p> </o:p><o:p> </o:p>The answers are in Layer-2, of course. The MAC addresses identify which of the routers of my Peers actually transmitted a packet to my router.<o:p></o:p><o:p> </o:p>Problems:<o:p></o:p>1/ I could try to tap off the interface and get a packet trace, <o:p></o:p>but I have to capture and identify a sample of the offending traffic, <o:p></o:p>2/ My peering router generates Netflow/IPFIX, but only populates Layer-3 data. Even if it did populate field 56 – Src MAC….<o:p></o:p>3/ In either case I need to get into the ARP cache to figure out which IP address the MAC address belongs to….<o:p></o:p><o:p> </o:p><o:p> </o:p>Suggestion:<o:p></o:p>Ask all IX customers to Embed the ASN into a Locally Administered MAC address on each peering interface.<o:p></o:p>First byte for Local flag, second byte for interface number, others for four-byte ASN<o:p></o:p>02:00:00:00:01:00 for ASN 256<o:p></o:p>02:00:00:00:04:F9 for ASN 1273 (first interface)<o:p></o:p>02:01:00:00:04:F9 for ASN 1273 (second interface)<o:p></o:p><o:p> </o:p>Now, if all peers have their router interfaces configured with these Local MAC Addresses, then a customer can capture the traffic and very quickly extract the identity of each Peer that is sending packets.<o:p></o:p>And peers can change their router hardware and still transmit from the same MAC address.<o:p></o:p><o:p> </o:p>Also, if I can get a peering Router to populate the Src MAC field of IPFIX and Netflow then I can start monitoring it all with flow reporting tools.<o:p></o:p><o:p> </o:p>Such MAC level encoding of ASN could be part of the peering agreement between organisations, or part of the requirement to connect to an IX RouteReflector.<o:p></o:p>Even as a voluntary recommendation it could cut down the workload of identifying where traffic is coming from.<o:p></o:p><o:p> </o:p><o:p> </o:p>I would appreciate your comments.<o:p></o:p><o:p> </o:p>I’ll be in Dublin too, if a discussion is worthwhile.<o:p></o:p><o:p> </o:p>Regards<o:p></o:p>Steve Nash<o:p></o:p></div></body></html>