Hello,
We're in the process of planning for an MPLS network that will use BGP for signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some outlining PEs? Are folks using dedicated/centralized Route Reflectors (redundant of course)? What about using some of the P routers as the Centralized Route Reflectors? The boxes aren't doing much from a Control Plane perspective, why not use them as Route Reflectors.
Any comments would be appreciated.
Thanks,
Serge
Hi there
The RR vs Full Mesh depends on what how you would like to balance your
exit/peering points across the network. If you have, say, 3 border
routers in 3 different regions, you should need at least 3 RRs if you
want each region having it's own preference for the external routes. I
would advise Full Mesh if the equipments can manage the number of iBGP
sessions and update-groups are quite fast this days, also the management
overhead is not much of an issue as "advertised".
About keeping the P routers as RR, I think that is will load the FIB
with useless external routes, and keeping them in a VRF is not quite OK,
depending on the used platform.
Pavel.
Serge Vautour wrote:
serge,
you can, and probably should, segment your mpls signalling ibgp from your internet/peering ibgp. in other words, on your pe, you configure ipv4/ipv6 bgp sessions to your peering/transit routers, then you configure mp-bgp sessions to three or four mpls vpn route reflectors. the mpls route reflectors do not participate in the actual routing of any packets (they don't set next-hop-self, only the pe routers would), their only function is to reflect the vpn signalling between disparate pe boxen.
similarly, if you have a very large number of pe routers, you can setup three or four boxes to reflect internet/customer routes...these boxes also would not route any packets, they would just reflect the non-mpls bgp sessions (they don't set next-hop-self, only the pe/transit/peering router do).
alternately, if you have local transit/peering routers at every pe site, then you can mesh all the transit/peering routers and have the local pe routers be rr clients of that site's transit/peering routers
hth
/joshua
Hi,
I have seen networks use the control plane of large P routers to reflect their inet-vpn routes. Keep in mind that when reflecting inet-vpn routes, the next-hops need to be "reachable". So quite possibly you will need some policy to resolve the MPLS next-hops.
Internet / VPN / and now IPv6 peers have different growth rates, so you may benefit in having different "types of route reflectors" for different address families.
In a small PE deployment (say, 5-50) PE nodes, you can deploy the route reflection on your P routers. Create some redundancy, and have your PE nodes peer with 2-3 of them. It keeps the configuration much smaller that having to define all the neighbours in a full mesh.
When you have lots of routes and PEs, you can start to have dedicated RRs for different address families.
Truman
Hi,
There are multiple ways you can solve that problem. We do the following:
1. Each region has its own ibgp cluster with 2 route reflectors
(usually the P nodes, since they seem to have abundance of CPU power
and not much to do with it).
2. All route reflectors (across regions) are fully meshed. We thought
a bit about creating two 'super' route servers, but then then number
of adjecencies is not that big ( we only have a few regions ).
Regarding internet traffic - we keep the Internet in a VPN, all PEs
that host that VPN are fully meshed and advertise only a default to
the common route reflectors (in their corresponding regions). Each
internet PE uses different RD, so there are multiple default routes
present in the regions.
kind regards
Pshem