Public Subnet re-assignments

Mel Beckman mel at beckman.org
Wed Jun 26 00:22:08 UTC 2019


Michel is right. This is a common configuration error: failing to have the mask agree on all interfaces. This is indeed what you would see.

 -mel

On Jun 25, 2019, at 4:07 PM, Michel Py <michel.py at tsisemi.com<mailto:michel.py at tsisemi.com>> wrote:

>  Scott wrote :
> No nothing like that. I'm just removing the .0/30 and 4/30 subnets and adding .0/29.
> To  your previous question, yes .0 and .3 are unused. Once I change the subnet .3
> becomes a usable IP and it's getting hammered with traffic, causing packet loss.

You change the subnet mask on both sides, right ?

Looks to me like expected behavior. On the sending router, with a /30 mask the .3 address is not usable, so the sending router does not send traffic.
When you change to the /29 mask, .3 becomes usable, the sending router ARPs it, and starts sending traffic.

In a way, that is possibly good news, as it allows you do find out that you may have a DOS or a DDOS attack going on your .3 address.

Michel.



On 6/25/19 3:30 PM, Mel Beckman wrote:
> Also, what do you mean by “join to /30 public subnets to a /29”? You can’t overlap subnets, if that’s what you’re thinking.
>
>  -mel
>
>> On Jun 25, 2019, at 3:27 PM, Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>> wrote:
>>
>> You’re using just the two middle IPs in the four that make up the /30 set, right? IOW, the subnet x.x.x.0/30 should have .0 and .3 unused (they’re broadcast), and you use .1 and .2.
>>
>> -mel
>>
>>> On Jun 25, 2019, at 9:41 AM, Scott <scott at viviotech.net<mailto:scott at viviotech.net>> wrote:
>>>
>>> First, sorry if this is a bit of a noob question.
>>>
>>> I'm trying to find a way of preventing a slew of traffic to an IP, or
>>> IP's, when I join two /30 public subnets to a /29. It appears that while
>>> the ranges are /30 someone is trying to brute-force the network and/or
>>> broadcast addresses for the ranges. When I change them to be a /29, now
>>> the router sees the traffic and starts dropping packets. Are there any
>>> suggestions for mitigating this behavior or is it just the nature of the
>>> beast?
>>>
>>> --
>>> 101010
>>>
>>>
--
101010

TSI Disclaimer:  This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190626/10b3cf92/attachment.html>


More information about the NANOG mailing list