I have read on some various websites and mailing lists that I subscribe to that it is a bad idea to carry customer prefixes in your IGP. Exactly why would this be? How do the rest of the routers in the network know how to get to your customer's prefixes if they are not in the IGP?
Depending on the nature of this article there might be several reasons. One, and the main one I would think, would be your IGP scalabitity. Say for example you carry all your customer prefixes and they mistakenly (or not) collect the entire internet routing table and redistribute that to you (say, from another IGP). You'd have close to 200K routes in your IGP.. .Melt down. Most Service providers would most likely have a separate IGP for just thier locally used prefixes as to not have the potential effect mentioned above. Also, if all your routers connecting the customer to the Internet were BGP speakers you'd really need no IGP to get your customer routes out . Just my 2 cents.
Yeah, it really is a bad idea to carry customer prefixes into IGP unless its needed very much. Imagine all the 100000+ routes in the internet on all the routers in your network. Mostly internal routers, doesnt need to know all the internet routes, unless the router is a POP router, running BGP. These routers can either run defaults to egress routers.
All this again depends on the topology of your network...If you dont plan to redistribute BGP routes into IGP, its better to have a full meshed IBGP between your routers, or a route reflector configuration ( if the number of IBGP sessions are large)
Yes, I know the implications of carrying a full routing table in the IGP, that's not what I am asking. When I think of "customer prefixes", I think of the networks that we have assigned to customers, or CIDR blocks that customers own. Customer prefixes are not the 120,000 internet routes. In any case, when you perform proper filtering, this will never happen anyway.
Maybe it's my own interpretation of the term "customer prefixes" that is confusing me?
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...