PSI/Digex announcements

Mailman List Mirror (Read Only)
1

I have a non peering T1 to PSI for VPN customers. While troubleshooting
some problems for one of those VPN customers I came across these:

HOUSTON_BR1#show ip bgp regex ^174$

   Network Next Hop Metric LocPrf Weight Path
*> 12.15.224.192/27 38.7.128.1 200 174 i
*> 154.32.255.0/30 38.7.128.1 200 174 i
*> 192.245.179.248/30 38.7.128.1 200 174 i
*> 198.17.203.0/25 38.7.128.1 200 174 i
*> 198.137.240.32/27 38.7.128.1 200 174 i
*> 198.207.208.192/27 38.7.128.1 200 174 iA
*> 204.4.196.32/27 38.7.128.1 200 174 i
*> 204.4.196.64/27 38.7.128.1 200 174 i
*> 204.4.196.96/27 38.7.128.1 200 174 i
*> 204.68.218.0/27 38.7.128.1 200 174 i
*> 204.180.67.160/27 38.7.128.1 200 174 i
*> 206.181.125.188/30 38.7.128.1 0 200 174 i
*> 206.119.241.96/27 38.7.128.1 200 174 i
*> 207.37.154.120/29 38.7.128.1 200 174 i
*> 207.138.126.128/27 38.7.128.1 200 174 i

Isn't it considered "bad" to be announcing nets that small, especially the
/30's?

2

Generally speaking, networks don't filter their announcements to their
own customers, or even in their core, except by special need.

Deepak Jain
AiNET

3

Right, but I thought aggregating routes (and these smaller subnets are all
from larger supernets advertised by PSI) was considered standard policy
and best practice when considering the size of the global routing table.

I have martian filters for BGP announcements from my upstreams to
accept nothing longer than a /24 as well as announcements for RFC1918
space that I shouldn't be seeing, but removed my filtering of PSI's
announcements to see what changes it made to my routing tables while
investigating what I believed to be a routing problem.

I was just shocked to see what I was told was bad practice from someone
like PSI.