I appreciate many people gave me advices,
Some of persons asked me about my questions, I'm sorry for that I couldn't reply to everyone.
Because of your help, I could get many opinions and standards regarding IP allocation policy.
by the way, in APNIC's IP allocation sizes policy, there is a comments like below.
"Below are the minimum sizes for allocations and assignments, This information is provided at the request of the ISP community
to assist in filtering policy decisions "
Currently, is there any provider filtering routes under LIR's minimum allocation size such as /22 ?
I appreciate many people gave me advices,
Some of persons asked me about my questions, I'm sorry for that I couldn't reply to everyone.
Because of your help, I could get many opinions and standards regarding IP allocation policy.
by the way, in APNIC's IP allocation sizes policy, there is a comments like below.
"Below are the minimum sizes for allocations and assignments, This information is provided at the request of the ISP community
to assist in filtering policy decisions "
Currently, is there any provider filtering routes under LIR's minimum allocation size such as /22 ?
Anyone running a platform that can't take a full table would apply such a filter to weed out anyone who likes to announce all of their space as /24's for "traffic engineering". If one does that and doesn't announce the aggregate as well, one could find themselves facing random black holes.
There's no "if" about it. Months ago when I and others were looking into this, we found plenty of examples of networks with /19s, /20s, etc. announcing only the /24 deaggregates. If you plan to filter these people and have customers to answer to, you'll need to point default at someone who's not filtering them.
Fully peered network A accepts routes from its peers based on prefix
allocation to AS maps.
Network B, which is either pathological (criminal, or bent on
censorship) or lacking clue, propagates /24 subnet of Network C's CIDR
(Pakistan/YouTube anyone).
If network A accepts Network B's announcement, then connectivity from
network A to the /24 announced by Network B (which isn't really
connected to network B) is either lost, or worse, hijacked.
Snarky replies aside, it might be interesting to hear if there are any real examples of this being done intentionally and not out of not knowing better or otherwise configuration error. For example, Tomas Byrnes's suggestion re: hijacking; although, I suspect that in that case, he's speaking of someone doing this filtering on a one-off basis and not on all /24's in the DFZ.
I help a buddy who works for a small ISP. I believe they're ignoring or
null routing large chunks of APNIC. Their customers are aware of the
policy, and cool with it. Port scanning and other malicious stuff
dropped 50% afterwards.
I help a buddy who works for a small ISP. I believe they're ignoring or
null routing large chunks of APNIC. Their customers are aware of the
policy, and cool with it. Port scanning and other malicious stuff
dropped 50% afterwards.
That sort of thing is common, sure (unfortunately).
My question (comment?) is more around why people would filter /24 (or whatever) prefixes (ie. when advertised a /24 prefix over BGP not accept it, so they do not get a route for that /24), and then not have a default. That route is used for outgoing packets, not incoming ones (modulo RPF, etc.).
The purpose of filtering the /24s is to keep the size of their RIB/FIB down, not to limit abuse or something. If you are close to the edge of the network, filtering /24s is a low hanging fruit way to catch a whole lot of pointless routes that don't really gain you much performance benefit, but are going to cost you lots of RIB/FIB space. However, you really need to have a covering default, so you still have some way to reach the people in those /24s.
Snarky replies aside, it might be interesting to hear if there are any
real examples of this being done intentionally and not out of not
knowing better or otherwise configuration error. For example, Tomas
Byrnes's suggestion re: hijacking; although, I suspect that in that
case, he's speaking of someone doing this filtering on a one-off basis
and not on all /24's in the DFZ.
Yep, that is what I'm interested in.
It would be perhaps an interesting exercise to only accept prefixes for which you do not have a covering prefix with the same next-hop, etc. I wonder if router vendors already do that internally as an optimisation when installing routes in to the forwarding hardware?
You would have to still have the routes in your RIB but RIB RAM is cheap(er).
Let me rephrase; Are there people who are filtering /24s received from
eBGP peers who do not have a default route?
of course.
Curiously, it was really meant as a rhetorical question where the answer was "no".
Why are people doing this? Are they lacking clue, or, is there some reasonable purpose?
Memory mostly I think. /24 prefixes are ~ the half of all prefixes, but they cover only a small percent of the address space.
If your router has > 6 full BGP sessions, you can filter /24 on half of them, your memory usage will drop significantly.
Also one of the reason why not putting default route may be because of
recursive lookup from routing table.
If you have multi-homed site within your network with static route, and
if you use next-hop IP address instead of named interface, you will see
the problem when you have default route in routing table.
For an example, if you have "ip route 1.0.0.0 255.0.0.0 2.2.2.2".
If the interface for 2.2.2.2 is down, 1.0.0.0/8 will be still be in the
routing table because 2.2.2.2 can be reached via default route
(0.0.0.0/0) from routing table recursive lookup.
Therefore the traffic for 1.0.0.0/8 will be forwarded to "0.0.0.0/0"
next-hop ip address, and customer fail-over scenario will not be working
at all.
Only way to resolve this problem is... Actually three...
1) Use named interface such as "serial 1/0" instead of "x.x.x.x" IP
next-hop address.
But sometimes this is not an option if you use ethernet circuit or
something like Broadcast or NBMA network.
2) Use BGP with private ASN...
3) Do not install default route in your routing table
