Jared, Oli,
The problems become more complex as you have this explosion happen
when someone else wants to do another hybrid solution.
useful, yes, but could also be expensive.. the more different services
you come up with, the more different routing table views you need to
provide, the more VRFs you need, and the more VRFs you have on a PE, the
more route duplication (on both control and forwading plane) you need to
do.. with the current Internet table size, this quickly becomes a
problem.
I don't think you need to duplicate entires in different tables to
provide portfolio of different services. All you need to be able to tell
on a per peer basis which tables his packets allowed to traverse. That
is very different from duplicate tables on a per set of services basis.
AFAIK Internet2 was first to deploy this solution and they were quite
happy about it.
Also from another point of view it seems completely feasible (see
cisco's route server context based architecture) to only provide per
neighbor specific policy and only copy to a neighbor
vrf/context/adj-rib-out the delta. Then during update generation you
advertise all common nets/paths from "one table" then the policy delta
from the per customer one.
Cheers,
R.
On Mar 15, 2012, at 9:39 AM, Jason Lixfeld wrote:
On 2012-03-15, at 8:29 AM, Oliver Boehmer (oboehmer) wrote:
useful, yes, but could also be expensive.. the more different
services you come up with, the more different routing table views
you need to provide, the more VRFs you need, and the more VRFs
you have on a PE, the more route duplication (on both control and
forwading plane) you need to do.. with the current Internet table
size, this quickly becomes a problem.
It's only expensive supposing you duplicate the Internet routing
table a whole heap of times. If Internet goes right into a VRF and
you have two more VRFs with, say,< 200 routes each, there's no way
an ASR9k or a 7600 won't handle that.
I once had a vendor pitch me the idea of having a few different
VRFs:
Internet (Customers + Peers) Customers (Customer routes, peer
interfaces would be in this VRF to avoid abuse) Whatever else one
wanted to do…
The problems become more complex as you have this explosion happen
when someone else wants to do another hybrid solution. Watch your
TCAM (7600 you mentioned above) start to disappear quickly, combined
with whatever complexities you dare add with dual-stack.
These days when talking to vendors and carriers, I do suggest asking
about IPv6 first. And call your IPv4 VRF "Internet-Classic"©(™)®*
- Jared _______________________________________________ cisco-nsp
mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
