08-27-2011 02:45 AM - edited 08-28-2017 10:18 PM
A. GPLS is more about L1 and MPLS VPN is L3
A. MPLS is required to be running in the Service Provider’s core network before we can use MPLS VPN.
A.Service Provider ensures that L2 is bridged over L3 network using MPLS. Basically, L2 encapsulation over MPLS network is done by Service Provider.
A. The services like DHCP, NAT on PE router has to be VRF aware, the CE device does not need to be VRF aware. So, this will be transparent for the customer.
A. This is done by importing RT in the VRF. So, we can communicate between VRFs if correct RTs are imported.
A. Unless we have alternate paths, routing loop is not a problem.
A. RD is per VRF and RT is per VPN across the network.
A. Yes, however it can create issues if same IPs and RDs are used as then there VPNv4 prefixes will be same and can cause issues.
A. Yes, using import-map.
A. Yes, MPLS does support IPv6. With 6PE and 6VCE MPLS VPN cab run IPv6 and IPv6 prefixes can be exchanged over BGP as core is running LSP and does not look at L3 information.
A. P router only has global/IGP routing table for the service provider. While PE router will have customer’s routing table and global routing table as PE only runs MPBGP.
A. Yes, but it depends on software.
A. PE-CE IGP can be different from what is run on CE (as customer’s IGP). We may have to redistribute routes between them to have complete connectivity.
A. Yes, using Label Switch Multicast (LSM).
A. Numeric keyword suppresses name lookup and hence we get faster results.
A. OSPF & IGP are used generally as they are vendor independent. Though EIGRP can also be used.
A. Same rule applies as in routing table, longest matched prefix is chosen.
A. VPLS runs on top of MPLS core. MPLS VPN can be L3 VPN or L2 VPN- wrapped inside MPLS.
A. MPLS labe comes between L2 and L3 header and as they both perform CRC check, checksum is not required.
A. TTL is to avoid looping in MPLS network.
A. LSP is label switched path, path between two PE routers.
A. In L2 VPN, Service provider does not get involve in routing, routing relationship is between customer sites. Example- Frame relay DLCI and ATM VC.
A.By using no mpls ip propagate-ttl command.
A. For hub and spoke, if hub only is required to speak to spokes not spokes to spokes, the one RT for hub and one for spoke is used. Hub will import spoke RT and spoke will import hub RT.
A. Yes, there will be a separate ospf process created for every vrf. Although you can create different process for the same vrf but for each different vrf, you cannot use the same ospf process. As you already know that the vrf routing table is different from the global routing table, so its always needed that separate processes be maintained for each routing table.
A. With EIGRP as PE-CE protocol, considering below 2 points as part of designing will help achieve your goal,
1. Having same EIGRP AS number on all PE devices for that VRF customer.
2. Manipulate BW/Delay parameters.
When a PE device redistribute vrf aware EIGRP into BGP, AS # will be carried as part of extended community in BGP Update to remote PE devices. Any remote PE device while redistributing BGP back into vrf aware EIGRP, will check if the AS # received in BGP Update and the EIGRP AS# to which this update is redistributed and see if they are same. If they are same, it will be advertised as Internal else will be advertised as external.
Once it is Internal, CE devices will decide the estpath based on lowest metric. So by manipulating the metric ( bya working on BW and or delay), your goal can be achieved.
Below is link which describes the extended community to carry EIGRP parameters, http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/fteipece.html
A. VRF is one of the key element that helps provide MPLS VPN service. VRF is VPN Routing and Forwarding instance which will build its own RIB and FIB table. By having each VPN customer associated to different VRF, privacy is acheived between customers.
Regarding multicast for VRF customers, current implementation is not label switched. Instead, multicast will be enabled on SP core with different group for each vpn customer. PE device on receiving any customer multicast traffic will encapsulate using GRE with destination address as multicast group for corresponding VRF customer and send across to other PE devices.
Below is the link to get more details about MVPN,
http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00800a3db6.shtml
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml
A. Current prefered way of Inter-VRF leaking in a controlled manner is to use export map and import map. This is also a scalable solution and so my understanding is you dont need any changes until you face any issue with this solution.
A. Actually MPLS is used by service providers but in case of enterprise want to use MPLS, they can use the vrf lite or if they are getting the connectivity from SP, in that case the migration is very easy because no need to change in enterprise.
The things which you need to understand is below mentioned:-
1. Which routing protcol you would like to run with SP?
2. Exiting IGP?
3. IPv6
4. For QOS you need to ask your SP and they will provide you the class details and mapping
A. LDP Identifier (48 bits) comprises of 32 bit "LDP Router ID" and 16 bits of "label space". It is not the filed where actual label will be advertised, but to inform neighbors about what label space the local LDP router is going to use. Is it per-interface space or per-platform space.
Actual label will be advertised in Label TLV which is of size 32 bits.
1. How do we monitor MPLS performance using Netflow?
Thanks Nagendra, for this excellent webcast..!!
-Bava
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: