Home page logo
/

nanog logo nanog mailing list archives

Re: 204.82.160.0/22 invisible
From: Curtis Villamizar <curtis () ans net>
Date: Wed, 27 Sep 1995 17:59:00 -0400


In message <Pine.SV4.3.91.950927113347.18109C-100000 () mercury sprintlink net>, E
lliot Alby writes:

SL-MAE-W#sho ip route 204.82.160.0
Routing entry for 204.82.0.0 255.255.0.0, supernet
  Known via "bgp 1239", distance 20, metric 1
  Tag 3561, type external
  Last update from 198.32.136.12 05:00:20 ago
  Routing Descriptor Blocks:
  * 198.32.136.12, from 198.32.136.12, 05:00:20 ago
      Route metric is 1, traffic share count is 1

198.32.136.12 = mae-west.SanFrancisco.mci.net

seems ok to me.

We put the /22 route in on Monday on a temporary basis despite the
lack of a route object, but Sprint is not announcing it.  The /16 was
already configured (last April based on the date in the route object).

Fix: Either get ANS to not insist on all routes being in the RADB or
submit an update to the RADB & wait for ANS to regenerate their
configs.

the latter is quicker and pragmatic. but i wish ans would quit splitting 
hairs on the subnet mask, we would need to submit so many less route 
objects.. 

- elliot alby/sprintlink


 1  en-0.enss470.t3.ans.net (204.148.1.30)  2.265 ms  2.066 ms  2.01 ms
 2  t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9)  27.96 ms  27.349 ms  27.415 ms
 3  mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222)  28.37 ms  27.288 ms  27.306 ms
 4  t3-2.cnss32.New-York.t3.ans.net (140.222.32.3)  30.487 ms  30.32 ms  30.806 ms
 5  t3-0.enss218.t3.ans.net (140.222.218.1)  36.292 ms  35.376 ms  35.682 ms
 6  sprintnap.mci.net (192.157.69.11)  37.03 ms  36.834 ms  37.303 ms
 7  border2-hssi1-0.NewYork.mci.net (204.70.45.5)  48.143 ms  41.863 ms  40.864 ms
 8  core-fddi-1.NewYork.mci.net (204.70.3.17)  44.199 ms  40.1 ms  43.824 ms
 9  core1-hssi-2.WestOrange.mci.net (204.70.1.98)  83.528 ms  46.626 ms  207.889 ms
10  core1-hssi-3.NorthRoyalton.mci.net (204.70.1.101)  270.636 ms  53.234 ms  53.712 ms
11  core-hssi-2.Chicago.mci.net (204.70.1.93)  66.218 ms  61.415 ms  60.72 ms
12  border3-fddi-0.Chicago.mci.net (204.70.2.83)  68.132 ms  61.701 ms  62.365 ms
13  canet.Chicago.mci.net (204.70.26.10)  82.314 ms  75.986 ms  76.336 ms
14  205.207.238.141 (205.207.238.141)  82.569 ms  77.25 ms  78.517 ms
15  205.207.238.93 (205.207.238.93)  98.424 ms  95.948 ms  100.419 ms
16  regional2.nb.canet.ca (192.68.57.102)  100.123 ms  97.174 ms  97.565 ms
17  tel.nbnet.nb.ca (198.164.29.66)  105.887 ms  104.426 ms  112.008 ms
18  198.164.27.14 (198.164.27.14)  128.397 ms !H *  133.737 ms !H

We are seeing a black hole at a CANET aggregate.  If Sprint would
announce the more specific /22 we would send the packet to Sprint
rather than to CANET by way of MCI.  Below is the registered aggregate
(with the list of holes removed).

route:       204.82.0.0/16
advisory:    AS690 1:3561(27)  2:3561(218) 3:3561(147) 4:3561(11)  5:3561(144)
descr:       NB-SCHOOLS
origin:      AS807
comm-list:   CANET_PROXY_AGGRS
mnt-by:      CANET-RC
changed:     config () canet ca 950406
source:      CANET

Isn't this the form of aggregation without fully considering topology
that we discussed at NANOG.  Sprint need to announce something more
specific than /16 and they need to register it so others know if you
are further aggregating the /22 or something.

Thanks,

Curtis



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]