165.138.0.0

Shawn David Solomon sdsolomo at iupui.edu
Thu May 28 16:54:32 UTC 1998


---------- Forwarded message ----------
Date: Thu, 28 May 1998 10:46:54 -0500 (EST)
From: Aaron Branham <abranham at ind.net>
To: Sean Donelan <SEAN at SDG.DRA.COM>
Cc: nanog at merit.edu
Subject: 165.138.0.0
 
 
Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see
a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 
(which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the 
classic /8 covering them and some don't.  It's the same story for 
several /16's (class b networks) I see 132.155.204.0/23 (without a /16 
anywhere),  134.128.52.0/24 (without a /16).  Do you have problems 
getting to all of these?
 
>From a router that has a customer connection to ANS, MCI, UUnet, and
Sprint 
I see all of our routes even though we only have uplinks to MCI and 
Sprint.  
 
This router has direct connects with MCI and UUnet and iBGP peers with a 
router that has the connections to Sprint and ANS.
 
Core#sh ip b reg _1767_
...cut....
* i165.138.96.0/20  208.160.14.1                  0      0 1239 1239 1767
i
* i                 208.160.14.1                  0      0 1239 1239 1767
i
*>                  166.48.222.45                 0      0 3561 3561 1767
i
*                   157.130.97.209                0      0 701 701 1239
1767 i
...cut....
 
This is the other router.....
 
...cut....
* i165.138.96.0/20  208.160.10.1                  0      0 3561 3561 1767
i
* i                 208.160.10.1                  0      0 3561 3561 1767
i
*                   192.103.62.121                0      0 1323 1673 3561
1767 i
*>                  144.228.13.229                0      0 1239 1239 1767
i
...cut....
 
The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and 
157.91.0.0 networks was to provide better service to our customers and to 
try and save IP address space for others.  Like some of the class A's 
above we treated these as CIDR blocks instead of going to our upstream 
providers or the ARIN to get more addresses.  Because our network has 
a dozen pops thoughout the state and each has at least one upstream 
connection to Sprint and MCI we advertise them as the /19's and /20's.  
This provides the greates redundancy for our customers.  Sprint's policy 
does not apply to customer routes so they do not filter at the /16 level 
for classic B addresses.  (They do for everybody else though....)  
Neither does MCI and it appears that ANS and UUnet do not filter with 
their connections to MCI and Sprint.
 
We have run this way for several weeks now and this is the first call on 
the problem that we have gotten.  But since the idea here is connectivity 
we'll re-announce the /16 from at least one of the POPs.  But in order to 
make sure the /16 is always routable we'll have to advertise it from 
every POP that has a /20 or /19 sub address.  Otherwise if the one POP 
advertising the /16 goes down our customers on the noted networks will 
loose connectivity to your network.  (We'll also have to put in a /16 
static route to overide the null0 that BGP will inject into our routing 
tables.)  It was much cleaner to just advertise the /19's and /20's 
without the /16 but we can (and I guess will have to unless you change 
your filters) do it the other way.
 
-
- Aaron Branham [AKB8] (a at ind.net) <Phone# 317.263.8976>
 





More information about the NANOG mailing list