Hello Martin,
Sorry, I wasn't too clear sir and apologies if I use the wrong words, I'm
not trained and so might stumble over my explanation.
In short I have two issues that I want to address.
1.
My bgp routers where I connect proividers feeds (ebgp i believe is the term
of the routers) are fine and have no ipv6 memory issues, at least none that
I'm aware of. But it was noticed that we accept ipv6 prefix lengths up to
/128.
So my initial question was a curiosity question, because I know my
predecessor configured the ipv4 bgp to not accept routes smaller than /24,
and given I don't really know that much about ipv6, I was wondering what
most the big boys do as standard. i.e .filter away anything smaller than
/48 etc.
>From reading the excellent advice received, I'm thinking I should filter
out nets smaller than /48s on my ebgp routers from the outside world.
But yes, I did muddle in my second problem in my mail because I"m stupid!
doh.
2.
I have some internal bgp routers (ibgp I think is the term, again sorry if
I'm using the wrong words), these are routers with no bgp transit
connectivity, just p2p links to other sites, where the ebgp transit
providers are that do, like the ones I talk about in (1) above.
Some of the internal bgp routers which bgp peer (ipv6) with the routers
which have ebgp transit, are running out of ipv6 memory and alerting in
syslog, counting down to judgement day. Friends who work at other
companies have told me horror stories of their routers recently crashing
when running out of memory for routes and I don't want that to happen to me.
I was muddling what I was saying earlier, very sorry. Here's my plan:
a) filter inbound ebgp routes from outside world, to /48 as mentioned
above, just so I'm not learning the ipv6 equivalent of ipv4's /32 nets etc.
(do this on my ebgp routers only)
b) push out default route from my ebgp routers to the ibgp routers (then
check the internal routers are receiving it/working). I will use ospf to do
this.
c) filter to /32 ipv6 from my ebgp routers to my ibgp routers, saving the
ibgps from running out of memory, while I sort out the undelying problem.
So my ebgp will have full ipv6 table with /48s being the smallest nets in
their table, and my ibgp v6 routers having ipv6 table down to /32's, no
smaller in size, but in addition a default route to ebgp ones. So the
default route would only be used by the ibgp routers for any ipv6 routes
they did not have, sending traffic to the ebgp routers, who do have more
memory and a full table.
I have done a near similar procedure but for ipv4 late last year as some
internal ibgp routers were running out of ipv4 bgp routes memory and this
sorted the issue, while the underlying memory problem was resolved. That's
all done now. About 1 week of that scary big problem sorted they started
alerting about ipv6 now running out of memory/routes. I did want to cry for
sure :)
Thank you kindly for your friendly, decent and patient email, I'm not used
to this! I ventured onto a certain distro of BSD mailing in the past to ask
for help and will never return to that one ;) heehehe.
Again apologies to all you clever people one here who are after reading my
mail probably want to sandpaper your eyes out at my clumsy language! I hope
I've at least tried to explain myself properly :)
I'm super happy with advice received and glad I asked. Have a great weekend
everyone!
Cheers,
Johnny
On 31 January 2014 15:30, Martin J. Levy wrote:
> John,
>
> I need to ask. Why the requirement to do such drastic filtering? The v6
> table size is pretty small. Plus you stated, after adjusting your own
> configuration, the /48 filter (the accepted common practice in v6-land)
> reduces cruft and provides a pretty clean table.
>
> Does the slightly less than 20,000 total routes (see
> http://bgp.he.net/report/prefixes#_prefixes plus other sites) cause you
> issues? Memory issues? Philosophical issues? Convergence issues?
>
> I'd strongly vote against you installing /32 filters for a few reasons. 1)
> The result won't be a complete (or valid, if you multi-home) routing table.
> 2) The implication of even one ISP doing this has ripples back to the RIR &
> ISP allocation world. 3) These kinds of filters NEVER get removed. 4)
> Default route doesn't really fix things. 2000::/3 route even more-so! 5)
> Memory is cheap.
>
> Or am I still missing something?
>
> Martin
>
> Martin J. Levy
> Director IPv6 Strategy
> Hurricane Electric
> 760 Mission Court,
> Fremont, CA 94539, USA
> +1 408 499 3801 (mobile)
> mar...@he.net (email)
> http://he.net/ (web)
>
> > On Jan 31, 2014, at 1:23 AM, john huss
> wrote:
> >
> > Hello,
> >
> > Thanks Daniel and Will, I appreciate your advice. Still learning abou
