Yes, the only thing that is necessary, in its most basic configuration, is the enabling of MPLS on the interfaces which connect PE1 and PE2 to the P router.
Can you be more specific as to what you’re having trouble with? Let us know so we can clarify it for you.
VPLS and H-VPLS are both technologies that use IP or MPLS networks to provide layer 2 connectivity between remote sites. This essentially allows dispersed sites to share a single Ethernet broadcast domain by connecting sites through what are known as pseudowires. This is a method of making L2 connections over an L3 infrastructure.
VPLS requires full mesh connectivity between sites, which is not very scalable. H-VPLS or Hierarchical VPLS is a method of allowing for scalability by dividing VPLS networks into two or three tiered hierarchical networks.
EVPN technologies provide similar services, but do so in different ways. The primary differences are:
Signalling
CE multihoming
MAC learning
More information about these differences can be found at the following links:
There are two ways to enable OSPF on particular interfaces. One is the way you mention, where you actually configure OSPF on a per interface basis. OSPF can also be enabled on an interface when the network address for the interface matches the range of addresses that is specified by the network area command that is entered in router configuration mode. Rene has applied the latter.
Note here that the ip ospf 1 area command is supported only by OSPFv2.
But it is still a little bit confusing how it was possible to pull out the information from router “P” with “show mpls ldp neighbor” if those interfaces weren’t set with IP yet.
By the way, could you also answer my question about RD and RT ?
Could be a very silly question, but just curious. PE1 and CE1 are having normal EBGP and neighbors are not defined under VPNV4 address family. Why still we need to use vpnv4 in the below show command to see the neighbor stats?
PE1#show bgp vpnv4 unicast vrf CUSTOMER summary
BGP router identifier 2.2.2.2, local AS number 234
BGP table version is 2, main routing table version 2
1 network entries using 160 bytes of memory
1 path entries using 56 bytes of memory
2/1 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 536 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.12.1 4 1 13 12 2 0 0 00:07:31 1
I went into the lab and attempted to use both the show bgp vpnv4 unicast vrf CUSTOMER summary command and the show bgp vrf CUSTOMER summary command and both resulted in the same output. The more correct command to use would be the latter since it specifically states what you want displayed.
The show bgp set of commands tend to assume certain things when you use them. For example if you simply issue the show bgp command, it will assume the ipv4 address family. In this case, there is only one VRF, so all configurations are assumed to be in that VRF, and thus both commands will result in the same output.
When you use the “source” keyword in the ping and traceroute commands, you are telling the router which interface, and thus which source IP address will be used for the sending and receiving of packets. If “source” wasn’t used, the router will automatically choose the IP of the exit interface as the source.
For example, if you ping 5.5.5.5 from CE1 without the “source” keyword, the ping will be sourced from the Fa0/0 interface which has an IP of 192.168.12.1. But the goal of the exercises is to see if the two loopback networks can communicate. By using “source” and the desired loopback, return packets will have a destination of 1.1.1.1, which is required to verify the desired connectivity.
Hi Laz,
Thank you for the explanation. So what config change would be required if we do not want to use source lo0? Since for PE1, 192.168.12.1 is directly connected. So the return packet should know the next-hop interface right if the source is physical interface?
The purpose of the lab was to allow connectivity between the 1.1.1.1/32 and 5.5.5.5/32 networks. This is why the ping was initiated using the loopback as the source. This was the requirement that had to be fulfilled and one way to test it is to use a ping from a source of 1.1.1.1 to verify connectivity between the specific networks.
If you don’t use the “source” keyword, then the source IP address that would be used is the IP address of the exit interface. In this case, with a destination of 5.5.5.5, the router will see from its routing table that the exit interface is Fa0/0 and would thus use 192.168.12.1 as the source IP address. This means that the echo request (ping) will use that address for the reply, so the return packet would have a destination of 192.168.12.1.
I’m trying to build the same network in packet tracer but the packet tracer is not supported to build bgp neighbor internally. Is there any other way to do the configuration on packet tracer. Or MPLS will work only in GNS3.
Unfortunately packet tracer does not support internal BGP peering nor does it support any MPLS features. Packet tracer was designed to cover the requirements of the CCNA level R&S certification. For more advanced topics you will have to use GNS3 or VIRL, or Netsim, but the latter two require some level of payment. The only free option is GNS3.
Hi Andrew,
In terms of the order of operations, when does RT on the destination PE comes to play? I don’t quite understand it, if MPLS VPNv4 label already knows which VRF to send the packet to, what’s the BGP VPNv4 RT role here?
Thanks,
Hani
This is an excellent question. This question clarifies the difference between the control plane and the data plane in an MPLS/Layer3 VPN environment.
The RT is involved in the exchange of routing information between CEs. It is used to allow CEs to export and import the correct routes (via the configuration on the PEs) so that CEs of particular customers can exchange routes correctly. The RT is involved in the control plane only.
Conversely, the VPN label is something that operates in the data plane. It is involved in the routing of data packets to the appropriate CE. When a packet reaches the PE, it must know to which VRF and to which customer the packet is destined for.
So the RT is involved in the import/export of routing information (control plane) while the VPN label exists on data packets and is used to determine which VRF (and ultimately which CE) the packet is destined for.
This is described in more detail in the following lesson:
Take a look especially at the sections titled RT (Route Target) and Transport and VPN Label.
BGP Labelled Unicast is a feature that provides MPLS transport across IGB boundaries. What this means essentially is that you can you can send MPLS bindings between administrative systems functioning with EIGRP, OSPF, or IS-IS for example. In this way, MPLS labels can be shared with remote areas not sharing the local IGP.
BGP-LU advertisements only impact edge routers and border routers and not the transport routers found within administrative systems.
You can see a detailed example of such a network, and how it uses BGP-LU at the following link: