MPLS: CE routers get other CE routes, but they're unreachable.

PE-1 is trying to Ping the remote CE from its source address in the VRF (configuration Below)
interface FastEthernet0/1
ip vrf forwarding A
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto

The routing table on CE-2 doesn't know where 192.168.1.1 is located. And it doesn't have a default route pointing to PE-2.

So what you need to do in BGP underneath the address-family ipv4 vrf A is add redistribute connected and it should work.

Also add redistribute connected to PE2.

Scales wrote: »

PE-1 is trying to Ping the remote CE from its source address in the VRF (configuration Below)
interface FastEthernet0/1
ip vrf forwarding A
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto

The routing table on CE-2 doesn't know where 192.168.1.1 is located. And it doesn't have a default route pointing to PE-2.

So what you need to do in BGP underneath the address-family ipv4 vrf A is add redistribute connected and it should work.

Also add redistribute connected to PE2.

I do have redistribute connected under the address-family configuration. That doesn't seem to be the issue.

Agent6376 wrote: »

I do have redistribute connected under the address-family configuration. That doesn't seem to be the issue.

woops. Sorry completely glazed over that when i read the configuration.

What does the show mpls forwarding table say on PE1?

Scales wrote: »

woops. Sorry completely glazed over that when i read the configuration.

NP, thanks for checking it out and your suggestion though.

Agent6376 wrote: »

NP, thanks for checking it out and your suggestion though.

What does the show mpls forwarding table say on PE1?

Million dollar command?

PE1# show mpls ldp neighbor

I reloaded my topology and realized that my MPLS config on my P routers was blown away, but basic connectivity/OSPF was running.

DOH!

haha nice one.

the loopback interfaces on the PE Routers is used to form neighborships for BPG VPNv4 so you dont get PHP happening to soon if you were to form neighborships with the directly connected link. The VRFs shouldn't have reachability to this as its part of the MPLS core and not the VPNs. HTH

kryolla wrote: »

the loopback interfaces on the PE Routers is used to form neighborships for BPG VPNv4 so you dont get PHP happening to soon if you were to form neighborships with the directly connected link. The VRFs shouldn't have reachability to this as its part of the MPLS core and not the VPNs. HTH

Once I got my MPLS P routers back online and I could ping across successfully, I noticed that the loopbacks are in the VRF even when everything is configured correctly.

I have a followup question as well:

Given the topology above, how would you configure this so that customers A and B could access the VOIP Gateway? Both sites would have routes to the gateway, but the VOIP Gateway can only have 1 192.168.1.x/24 and 192.168.2.x/24 in it's routing table.

Thoughts?

Agent6376 wrote: »

Once I got my MPLS P routers back online and I could ping across successfully, I noticed that the loopbacks are in the VRF even when everything is configured correctly.

I have a followup question as well:

Given the topology above, how would you configure this so that customers A and B could access the VOIP Gateway? Both sites would have routes to the gateway, but the VOIP Gateway can only have 1 192.168.1.x/24 and 192.168.2.x/24 in it's routing table.

Thoughts?

I dont understand how the VPNs has the routes to PE loopbacks which are in the global routing table..The VOIP gateway you can do VRF aware NAT on the PE routers and how are the PEs getting the routes from the VOIP gateway

Agent6376 wrote: »

but they're pointing to the loopback interface of the PE router

are you talking about the BGP next hop if so then that is correct because you're peering with the loopbacks but you cannot ping this from the VRF as this is part of the global routing table. Inside the MPLS core the routers are label swapping according to what label they have allocated to the BGP next hop that is why the P routers doesnt need to know all the routes of the VPN, they only need to know do I have a label to reach the next hop and in mpls there is no routing table lookup all I need is what label comes in, swap it with the outgoing label and what interface to send it out on and all this is in the mpls forwarding table.

kryolla wrote: »

are you talking about the BGP next hop if so then that is correct because you're peering with the loopbacks but you cannot ping this from the VRF as this is part of the global routing table. Inside the MPLS core the routers are label swapping according to what label they have allocated to the BGP next hop that is why the P routers doesnt need to know all the routes of the VPN, they only need to know do I have a label to reach the next hop and in mpls there is no routing table lookup all I need is what label comes in, swap it with the outgoing label and what interface to send it out on and all this is in the mpls forwarding table.

I am referring to the BGP next hop, yes. I'm confused on why the BGP next hop is being shown in the VRF, if there's no way that the VRF will ever be able to reach the address? At what point does the MPLS label forwarding begin?

CustA_CE1 pings 10.10.10.10. Checks routing table and the next hop is 192.168.1.1.

PE1 receives the packet on the interface labeled VRF A, so it appends the RD 1:100 to the packet and creates the VPNv4 prefix. It checks the route-target export and sees that it uses 1:100 as well. It checks it's next hop for 192.168.1.1 and sees that it's at 2.2.2.2 (via iBGP). Checks the LFIB and sees prefix 2.2.2.0/30 has a label of 17 so it uses MPLS to forward the packet.

Packet traverses MPLS core, P4 pops the top label and PE2 receives the VPNv4 packet. PE2 checks the route-target label and looks at the local import table for the configured VRFs. It sees that vrf A has the route-target import 1:100 command entered, so it peels off the route-target information and places the ipv4 prefix in the VRF table (iBGP prefix now)

Normal EBGP peering between CustA_CE2 takes place and the prefix is sent to CE2 where it hits the routing table.

Some areas are a little gray and I need to review (such as the route target import/export process - isn't a label added?) But I'm hoping I have at least the 1000 foot view down.

Your thoughts?

Agent6376 wrote: »

I am referring to the BGP next hop, yes. I'm confused on why the BGP next hop is being shown in the VRF, if there's no way that the VRF will ever be able to reach the address? At what point does the MPLS label forwarding begin?

CustA_CE1 pings 10.10.10.10. Checks routing table and the next hop is 192.168.1.1.

PE1 receives the packet on the interface labeled VRF A, so it appends the RD 1:100 to the packet and creates the VPNv4 prefix. It checks the route-target export and sees that it uses 1:100 as well. It checks it's next hop for 10.10.10.10 vpnv4 label and sees that it's at 2.2.2.2 (via iBGP). Checks the LFIB and sees prefix 2.2.2.0/30 has a label of 17 transport label so it uses MPLS to forward the packet.

Packet traverses MPLS core, P4 pops the top label and PE2 receives the VPNv4 packet. PE2 checks the route-target label and looks at the local import table for the configured VRFs. It sees that vrf A has the route-target import 1:100 command entered, so it peels off the route-target information and places the ipv4 prefix in the VRF table (iBGP prefix now)

Normal EBGP peering between CustA_CE2 takes place and the prefix is sent to CE2 where it hits the routing table.

Some areas are a little gray and I need to review (such as the route target import/export process - isn't a label added?) But I'm hoping I have at least the 1000 foot view down.

Your thoughts?

the PE router puts a VPN label for the VPNv4 prefix then it puts another label for the next hop which is the transport label. This label is what gets swapped in the MPLS core and the PHP router will pop the transport label and send the VPNv4 label to the PE router. If the P router pops the transport label to early it will expose the VPNv4 label and the nex P router doesnt know what to do with it that why you peer with the loopback and not the directly connected link between the P and PE routers. Look at how the control plane works and then how the data plane forwards traffic.

I'll have to review the concepts once again to make sure I understand the process from end to end, but I'm feeling pretty good about it at this point. I want to get the core of L3VPNs and MPLS operation down before moving on to TE/L2TPVPN etc.

Thanks a bunch!

RE VPN Packet Forwarding:

CE-1 Sends a packet to CE-2 (both in the same MPLS VPN)
The packet arrives at PE-1.
PE-1 performs a route lookup and based on the destination performs label imposition (Push Operation).
Bottom Label (S-bit on) is the VPN label assigned by PE-2.
Top Label (S-Bit off) is the Label to reach PE-2.
Label Switching is performed based on the top label until it reaches the P router before PE-2. This router performs PHP and sends the packet to PE-2 with only the VPN Label. PE-2 sends the packet to CE-2 based on the VPN label it assigned and sent to PE-1 using MP-BGP.

The VOIP Gateway:
You want to create a Central Services VPN.

I found a very good resource for the detailed operation from end to end for MPLS VPNs. It documents the MPLS VPN control and data planes thoroughly, and is a great read. If anyone is just getting into MPLS, it's a great read to clear up a good bit of questions.

Multiprotocol Label Switching > MPLS VPNs

Scales wrote: »

RE VPN Packet Forwarding:

The VOIP Gateway:
You want to create a Central Services VPN.

what if the Gateway wasnt in a VPN but in the global routing table, he didnt specify but central services usually involves loopbacks advertised with a specific RT and the op says the gatway only has routes to 192.168.1 and .2 networks and since the same networks are used on 2 different VPNs, NAT is a possible solution. Also no routing is performed in the MPLS core thats why its called label switching and its based on the cef entry and mpls forwarding table with the exception of the PE router.

kryolla wrote: »

what if the Gateway wasnt in a VPN but in the global routing table, he didnt specify but central services usually involves loopbacks advertised with a specific RT and the op says the gatway only has routes to 192.168.1 and .2 networks and since the same networks are used on 2 different VPNs, NAT is a possible solution. Also no routing is performed in the MPLS core thats why its called label switching and its based on the cef entry and mpls forwarding table with the exception of the PE router.

Yep exactly. What if.

and yes there is routing in the MPLS Core, but yes the packet would be label switched not routed.

Scales wrote: »

Yep exactly. What if.

and yes there is routing in the MPLS Core, but yes the packet would be label switched not routed.

I was talking about traffic from 1 VPN site to another VPN site. There is no routing lookups done in the MPLS core with the exception of the PE routers

kryolla wrote: »

I was talking about traffic from 1 VPN site to another VPN site. There is no routing lookups done in the MPLS core with the exception of the PE routers

then why didn't you say that.

Scales wrote: »

then why didn't you say that.

because you said this

Scales wrote: »

RE VPN Packet Forwarding:

CE-1 Sends a packet to CE-2 (both in the same MPLS VPN)
The packet arrives at PE-1.
PE-1 performs a route lookup and based on the destination performs label imposition (Push Operation).
Bottom Label (S-bit on) is the VPN label assigned by PE-2.
Top Label (S-Bit off) is the Label to reach PE-2.
Routing is performed based on the top label until it reaches the P router before PE-2. This router performs PHP and sends the packet to PE-2 with only the VPN Label. PE-2 sends the packet to CE-2 based on the VPN label it assigned and sent to PE-1 using MP-BGP..

so it was inferred I was talking about VPN forwarding but I guess you need it spelled out so why dont you go back and study your CCNA material

kryolla wrote: »

because you said this

so it was inferred I was talking about VPN forwarding but I guess you need it spelled out so why dont you go back and study your CCNA material

What exactly is your problem?

Edit: Changed from Routing to Label Switching. Happy Now?

Scales wrote: »

What exactly is your problem?

Edit: Changed from Routing to Label Switching. Happy Now?

lets start here

Scales wrote: »

PE-1 is trying to Ping the remote CE from its source address in the VRF (configuration Below)
interface FastEthernet0/1
ip vrf forwarding A
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto

The routing table on CE-2 doesn't know where 192.168.1.1 is located. And it doesn't have a default route pointing to PE-2.

So what you need to do in BGP underneath the address-family ipv4 vrf A is add redistribute connected and it should work.

Also add redistribute connected to PE2.

If the BGP next hop was inaccessible it wouldn't have made it to the routing table due to it not being a best route