5 Apr
2021
5 Apr
'21
4:51 p.m.
So? It reaches ucsd.edu as per the 44.128.0.0/10 public BGP route (as
expected) and gets dropped.
In the tunnel RIP messages it will never get announced, so there is no
impact on another possible system using it.
No harm done and I do not see a problem with this.
On 06/04/2021 00:26, K7VE - John via 44Net wrote:
root@vpn:/var/www/html# traceroute 44.128.0.1
traceroute to 44.128.0.1 (44.128.0.1), 30 hops max, 60 byte packets
1 10.0.0.49 (10.0.0.49) 0.297 ms 0.292 ms 0.322 ms
2 six.core1.sea1.fiberhub.net (206.81.80.229) 4.665 ms 4.681 ms 4.666
ms
3 129.250.199.57 (129.250.199.57) 5.645 ms 5.636 ms 5.619 ms
4 ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133) 6.014 ms
ae-8.r24.sttlwa01.us.bb.gin.ntt.net (129.250.5.117) 5.820 ms
ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133) 5.807 ms
5 ae-1.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.207) 5.150 ms
ae-0.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.99) 5.165 ms 5.154 ms
6 ae-0.level3.sttlwa01.us.bb.gin.ntt.net (129.250.9.181) 5.118 ms 5.507
ms 5.508 ms
7 * * *
8 CENIC.ear1.SanJose1.Level3.net (4.15.122.46) 18.255 ms 18.277 ms
18.303 ms
9 dc-svl-agg8--svl-agg10-300g.cenic.net (137.164.11.81) 27.314 ms
27.300 ms 26.575 ms
10 dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0) 27.999 ms
lax-agg8--svl-agg8-100g-3.cenic.net (137.164.11.66) 28.031 ms
dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0) 28.082 ms
11 dc-tus-agg8--lax-agg8-300g.cenic.net (137.164.11.83) 27.978 ms 27.969
ms 28.123 ms
12 dc-sdg-agg4--tus-agg8-300g.cenic.net (137.164.11.85) 28.347 ms 28.392
ms 28.270 ms
13 dc-ucsd-100ge--sdg-agg4.cenic.net (137.164.23.177) 28.201 ms 28.227
ms 28.053 ms
*14 nodem-core-6807-vlan2767-gw.ucsd.edu
<http://nodem-core-6807-vlan2767-gw.ucsd.edu> (132.239.254.61) 28.251 ms
28.397 ms 28.198 ms15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu
<http://sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu> (132.239.255.50) 28.860 ms
28.583 ms 29.149 ms*
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
On Mon, Apr 5, 2021 at 2:18 PM Marius Petrescu via 44Net <
44net(a)mailman.ampr.org> wrote:
The 44.128.0.0/16 block, by definition, will
never be forwarded,
announced or allocated.
There will never be someone using it later, outside the scope of a
non-connected testing environment.
Why isn't that good enough?
To get more confusion to the less technical people not being able to
distinguish between a potential valid RFC 5737 address in their own
private address space and a 44net address?
BTW, 10.0.0.0/8 addresses are quite often used by providers for their
infrastructure, so randomly playing around with them could actually
trigger side effects that are very hard to track down, especially for
some (I have as an example 2 providers, both have their PPPoE endpoint
in the 10/8 space).
I would really go with the 44.128.0.0/16 (as I did in all my examples
related to my code - it will just not work if they do not update it
correctly).
Marius, YO2LOJ
On 05/04/2021 23:07, K7VE - John via 44Net wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
This is why I suggested the 10.44.x.x and
192.168.44.x blocks -- the
'*44*'
is a consistent clue for documentation, and yet
would not be
routable beyond the LAN if copied.
This may be a topic for the TAC
On Mon, Apr 5, 2021 at 12:45 PM Antonios Chariton (daknob) via 44Net <
44net(a)mailman.ampr.org> wrote:
> I’ve seen a company that had problems with people copy pasting blindly
and
> not changing the settings use something
equivalent to 44.256.0.0. Since
256
> is not valid, it could break, and you’d go
back and see you needed to
> replace something. Interesting solution that was guaranteed to work :)
>
>> On 5 Apr 2021, at 21:40, Jason McCormick via 44Net <
> 44net(a)mailman.ampr.org> wrote:
>> RFC5737 doesn't support this use case which is why I asked in the first
> place about a dedicated documentation block to begin with.
>> The point of having a 44Net documentation block is so that it's
> painfully obvious that "YOUR ALLOCATION GOES HERE". The point of posting
> stuff on the GitLab server and hopefully other places is precisely to
"copy
> documentation" and use it. Yes, there
will always be those people who
> literally apply no thought to cutting-and-pasting in something but we
can't
> do anything about that. My interest is having
configuration that someone
> CAN literally copy/paste, make some very minor tweaks, and get their
system
> running. Using a random RFC5737 address block
which likely most people
have
> never heard of isn't going to be helpful
in reducing the learning curve
and
confusion.
> However using the test space probably makes sense since that is the
literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.
> For what it's worth, I will be using 44.128.50.0/24 for my stuff.
>
> Jason
------------------------------
John D. Hays - K7VE
Kingston, WA
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net