Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
com/in/syarifuddin
Chapter 1 Basic :
http://www.slideshare.net/ariefcakep/mpls-deployment-chapter-1-basic1
Chapter 2 Services :
http://www.slideshare.net/ariefcakep/mpls-deployment-chapter-2-services1
Chapter 3 Optimization :
http://www.slideshare.net/ariefcakep/mpls-deployment-chapter-3-optimization
Bank BCA wants to subscribe MPLS Link over all of the branches in indonesia using L3VPN/VPRN through our backbone network. The branch offices are 8 : Jakarta1, Jakarta2, Bogor, Bekasi, Surabaya, Malang, Madiun, Banjarmasin Datacenter is located in Tangerang City All BCA Routers connected to each 9 PEs.
Logical Topology
One of VPRN/L3VPN problem is, to comply with such topology, and to connect all client routers, iBGP Peering on the PEs must be fully meshed on each others. This could become a painful jobs when we add one or more network into current vrf, we need to reconfigure all related vrf PE, to do full mesh iBGP peering. Peer formula = n(n-1)/2, n stands for number of routers, For example 9 routers, will need 41 peer connection 10 routers, will need 45 peer connection 25 routers, will need 300 peer connection 50 routers, will need 1225 peer connection
! address-family vpnv4 neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.13 activate neighbor 10.0.0.13 send-community both exit-address-family !
! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community both neighbor 10.0.0.6 activate neighbor 10.0.0.6 send-community both neighbor 10.0.0.7 activate neighbor 10.0.0.7 send-community both neighbor 10.0.0.9 activate neighbor 10.0.0.9 send-community both neighbor 10.0.0.10 activate neighbor 10.0.0.10 send-community both neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both exit-address-family !
Route Reflector / RR are an alternative way to provide full meshed iBGP peers. One or more routers configured as a route reflector, while the remaining iBGP routers are configured as clients and peer only with route reflector forming a Route Reflector Cluster. This reduces the number of connections required to the number of clients. Routing updated received by a client are sent to the Route Reflector and it will forward to other clients in the cluster.
RR Deployment Methods Option 1 involves using the PE router as the VPNv4 RR as well.
This type of setup is not recommended due to additional constraints of memory and CPU imposed on the PE router that acts as RR, which is handling both the functions of providing services to client edge routers as well as reflecting routes to several other PEs in the same MPLS domain. The P router handles not only the function of route reflection for IPv4 and VPNv4 routes, but also performs data forwarding operations for IPv4 and VPNv4 traffic. This scenario may not scale well in large MPLS VPN environments due to memory and CPU constraints imposed on the RR that not only provides IPv4 and VPNv4 routing services but also data forwarding functionality.
Option 2 involves using the P router as an RR for both IPv4 and VPNv4.
Option 4 involves a dedicated router performing the function of reflecting IPv4 and VPNv4 routes. The router does not perform any data forwarding functions.
This implementation can be used in large-scale MPLS VPN environments in which the provider network wants to isolate IPv4 functionality on the VPNv4 RR.
This scenarios also increases the provider's operational costs because the provider has to dedicate routers RRs for IPv4 and VPNv4 prefixes as well as ensure their PE routers have physical connectivity with each other for data forwarding functionality or are connected to a dedicated P router, which perform data forwarding functionality.
Option 5 involves a dedicated router as a RR for only VPNv4 routes and not for data forwarding. Like the last option, there is considerable savings in CPU and performance improvements can be realized but at the cost of additional routers providing provider router functionality and increased cost in providing physical connectivity between PE and P routers. Option 6 involves partitioned RRs, which is primarily in largescale environments in which using a dedicated VPNv4 RR does not scale to the demands of a large provider carrying a large number of VPNv4 prefixes.
Use PE as supported RR
For this case, IPv4 BGP Peering is fully meshed (light red color) but VPNv4 BGP peering is configured through RR (P Router)
IPv4 BGP Peering is fully meshed (light red color) but VPNv4 BGP peering is configured through dedicated RR
BGP VPNv4 peering for each VRF are divided to different RR, to reduce the load of BGP Process
Due to lack of operational budget, team will use Option 1 for RR Deployment Method. This solution is Temporary, and is proposed on next budget to bought additional dedicated RR Routers to do the job.
Positive impact :
Simplify BGP Configuration BGP Peering kept Redundant It also makes BGP process low on all non RR PE Routers. Easy to do expansion for the current VRF
Negative impact :
For the rest of PEs, only need to peer to the RR1 and RR2
PEJBRBGR01 (Loopback 10.0.0.6)
router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 10.0.0.3 remote-as 65100 neighbor 10.0.0.3 update-source Loopback0 neighbor 10.0.0.4 remote-as 65100 neighbor 10.0.0.4 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both exit-address-family !
For the rest of PEs, only need to peer to the RR1 and RR2
PEJTMMLG01 (Loopback 10.0.0.10)
router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 10.0.0.3 remote-as 65100 neighbor 10.0.0.3 update-source Loopback0 neighbor 10.0.0.4 remote-as 65100 neighbor 10.0.0.4 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both exit-address-family !
For the rest of PEs, only need to peer to the RR1 and RR2
PEKALBJM01 (Loopback 10.0.0.13)
router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 10.0.0.3 remote-as 65100 neighbor 10.0.0.3 update-source Loopback0 neighbor 10.0.0.4 remote-as 65100 neighbor 10.0.0.4 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community both neighbor 10.0.0.4 activate neighbor 10.0.0.4 send-community both exit-address-family !
BGP neighbor with RR were UP, but the state is NoNeg, because we only use the MPBGP feature.
By using show ip route vrf vrf_name, we can see the route for current vrf over the MP-BGP
Ping & Traceroute vrf can be used to test connectivity from PE to CE. Also can be used to check MPLS label & VPN Label
Thankyou
RR Implementation in MPLS VPN Cisco Support https://supportforums.cisco.com/docs/DOC-32629 BGP Case Studies Cisco Systems http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml BGP Route Reflectors Example http://ccnprecertification.com/2005/10/13/bgp-route-reflectors-example/ CCNP Practical Studies: Routing | Scenario 7-1, Configuring Route Reflectors http://www.informit.com/library/content.aspx?b=CCNP_Studies_Routing&seqNum=89 Route-Reflectors and Confederations in MPLS VPN Networks http://mynetworkingwiki.com/index.php/RouteReflectors_and_Confederations_in_MPLS_VPN_Networks