Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


ARP broadcast consumes billing traffic
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

ARP broadcast consumes billing traffic

Found that idle gcorelabs server is steadily wasting the traffic in my quota every day, all from the ARP request inside the VLAN, and technical support said "there is nothing to fix".

Is this common, or just my overreaction?

Comments

  • Jona4sJona4s Member

    arptables -A INPUT --source-mac de:ad:be:ef:ba:be -j DROP

  • @Anoneko said:
    Found that idle gcorelabs server is steadily wasting the traffic in my quota every day, all from the ARP request inside the VLAN, and technical support said "there is nothing to fix".

    Is this common, or just my overreaction?

    It shouldn't be a lot in the grand scheme of things, but if this was a Sat link or expensive data, the "nonzero" cost might be annoying.

  • @Jona4s said:
    arptables -A INPUT --source-mac de:ad:be:ef:ba:be -j DROP

    Umm, if his arptables can receive the packet to drop it, it was already counted/billed. And not responding to arp requests will only increase packet count, not reduce it.

    He needs the switch to STFU, or traffic not counted.

    Thanked by 2jsg Anoneko
  • Jona4sJona4s Member

    what? how does not responding increases the packet count?

    If anything it will cut it by half.

  • SplitIceSplitIce Member, Host Rep
    edited July 2020

    How many arps are you receiving that they would even register?

    For it to matter I'm betting you would need to be receiving at-least 100k PPS worth of ARPs (~2-4mbps).

  • cochoncochon Member

    @Jona4s said:
    what? how does not responding increases the packet count?

    If the ARP question isn't answered (and then cached) it will keep getting repeated every time it's wanted. Though in this case I suspect the requests are not for the server box itself, if so, the impact is rather neutral.

    Thanked by 1TimboJones
  • @SplitIce said:
    How many arps are you receiving that they would even register?

    For it to matter I'm betting you would need to be receiving at-least 100k PPS worth of ARPs (~2-4mbps).

    Honestly, not much, it costs about 120GB per month. But I use a very limited data plan that only provides 500GB of traffic (in and out), so it still hurts a bit.

  • SplitIceSplitIce Member, Host Rep

    120GB/month? That's billions of ARP messages per month or at-least 1.2k packets per second.

    That's not normal. I've never been on a network with that high of an ARP rate. I would expect it could be possible on a large non-vlan network (but most large providers use VLANs). I would:

    1. Confirm that you are not mistaken.
    2. Use tcpdump to capture a pcap file (tcpdump -w arp.pcap -n arp)
    3. submit a PCAP file with your ticket. Explaining that this.

    To help your case I would also suggest performing analysis on the arps. Check to see if it's one hardware address or ip address being requested.

    Thanked by 1Anoneko
  • SplitIceSplitIce Member, Host Rep

    @cochon said: If the ARP question isn't answered (and then cached) it will keep getting repeated every time it's wanted. Though in this case I suspect the requests are not for the server box itself, if so, the impact is rather neutral.

    Sure if someone was constantly requesting 1,000+ non-existing IPs and their ARP timeout/retry was ~1 second (I'm not sure what the normal default is for this). For existing IPs the default cache period I've most seen is 30-60 seconds so we are talking a network with at-least 40k IPs in constant use (without VLANs).

    ARP messages are pretty fast to handle (and small) providing there is no arptables rules so I doubt this would be too heavy on CPU or resources. Still thats alot of PPS for no reason and OP is well within his rights to request it resolved. Expecially on a low-end deal (low bandwidth, possibly low CPU)

  • @SplitIce said:
    120GB/month? That's billions of ARP messages per month or at-least 1.2k packets per second.

    That's not normal. I've never been on a network with that high of an ARP rate. I would expect it could be possible on a large non-vlan network (but most large providers use VLANs). I would:

    1. Confirm that you are not mistaken.
    2. Use tcpdump to capture a pcap file (tcpdump -w arp.pcap -n arp)
    3. submit a PCAP file with your ticket. Explaining that this.

    To help your case I would also suggest performing analysis on the arps. Check to see if it's one hardware address or ip address being requested.

    Thanks, I will discuss with them further.

  • avelineaveline Member, Patron Provider

    Gcore.lu allocate all customers in the same VLAN by default and you'll need to pay at least 30 EUR to get dedicated VLAN to avoid these ARP traffic and hijacking.

    Good luck :-D

    Thanked by 1muhfugen
  • jsgjsg Member, Resident Benchmarker

    @Jona4s said:
    what? how does not responding increases the packet count?

    If anything it will cut it by half.

    No. Nothing one filters out on a systems firewall will reduce traffic costs because it's already on the system anyway. Also ARP is no for the fun of it protocol, it's (usually) needed and ignored requests will trigger new attempts.

    Looking at how to analyse and solve the problem @SplitIce already has provided useful input that should be considered.

  • muhfugenmuhfugen Member
    edited July 2020

    @aveline said:
    Gcore.lu allocate all customers in the same VLAN by default and you'll need to pay at least 30 EUR to get dedicated VLAN to avoid these ARP traffic and hijacking.

    You dont even need a dedicated VLAN. OP's provider is incompetent as are these other providers. All you need is a isolated PVLAN, and everyone placed in it ends up in their own broadcast domain, and you're not wasting VLANs. There is no reason for multiple customers to share a broadcast domain, and its just a sign of a provider who cant hire experienced network engineers.

Sign In or Register to comment.