Brad, I will try to explain in more detail what is happening, I cannot recreate because I don't have your full configs but I think I understand the gist of your issue.
Looking at this from R1 (ingress) going towards R2 (egress)... R1 has a route in the VRF (192.168.2.2) with a next-hop of 192.168.2.1. R1 builds the labeled packets as follows: Inner label = assigned to 192.168.2.2 (learned via VPNv4) Outer label = assigned to 192.168.2.1 (learned via OSPF/LDP) The problem is 192.168.2.1 belongs to the network 192.168.2.0 for which Core router has advertised a POP label to R1. When R1 builds the labeled packet for 192.168.2.2 it puts the label it learned from R2Core (label 22) and a POP label (which is no label at all). When Core router gets the packet, it has label 22. Core router does not have label 22 in its LFIB and this breaks the LSP...Core router drops the packet. If you peered with the loopbacks, the Core router would not advertise a POP label for R2Core's loopback, it would advertise a real label and Core could switch it correctly. For what its worth, you may try and configure explicit-null on each core router...I have not treid this myself. As you can see, they is to not expose the VPN label before it reaches the egress PE. If you want to see what labels are getting attached to the network, try this command on a PE. show ip cef vrf BRAD 192.168.2.2 On Sat, Nov 21, 2009 at 10:26 AM, Bryan Bartik <[email protected]> wrote: > Brad, > > There are at the least a few issues with the configuration, perhaps you are > misunderstanding how the LSP is built. There is no problem with your route > advertisements, the problem is with the label switched path between the PEs. > What are you using as your reference? > > > On Sat, Nov 21, 2009 at 9:31 AM, Brad Edgeworth <[email protected] > > wrote: > >> I thought the iBGP route-reflector-client would allow the routes learned >> from R1Core to R2Core. It appears as if that is working? Can you explain >> the flaw in my logic? Curious as to why the subnet id’s need to match >> for the loopbacks? I noticed that some of the VRF routes are not in the >> mpls forwarding table. Is that normal? >> >> >> >> My regular R1 & R2 routers (Naming convention wasn’t the greatest) aren’t >> running BGP and do not have VRF apply. VRF is defined only on R1Core & >> R2Core. >> >> >> >> >> >> More Info from the original configs: >> >> >> >> R1: >> >> Show ip route >> >> 10.0.0.0/24 is subnetted, 2 subnets >> >> C 10.32.1.0 is directly connected, FastEthernet0/0 >> >> O E2 10.64.1.0 [110/1] via 10.32.1.254, 11:03:48, FastEthernet0/0 >> >> C 192.168.1.0/24 is directly connected, Loopback0 >> >> 192.168.2.0/32 is subnetted, 1 subnets >> >> O E2 192.168.2.2 [110/2] via 10.32.1.254, 11:03:50, FastEthernet0/0 >> >> >> >> R1Core: >> >> Sho ip route >> >> 172.32.0.0/24 is subnetted, 2 subnets >> >> C 172.32.32.0 is directly connected, FastEthernet0/1 >> >> O IA 172.32.64.0 [110/129] via 192.168.1.254, 10:57:30, Serial0/0 >> >> C 192.168.1.0/24 is directly connected, Serial0/0 >> >> O 192.168.2.0/24 [110/128] via 192.168.1.254, 10:57:32, Serial0/0 >> >> 92.168.100.0/24 is variably subnetted, 3 subnets, 2 masks >> >> C 192.168.100.0/24 is directly connected, Loopback0 >> >> O 192.168.100.2/32 [110/129] via 192.168.1.254, 10:57:32, Serial0/0 >> >> O 192.168.100.254/32 [110/65 <http://192.168.100.254/32%5B110/65>] >> via 192.168.1.254, 10:57:32, Serial0/0 >> >> >> >> Sho ip route vrf BRAD >> >> 10.0.0.0/24 is subnetted, 2 subnets >> >> C 10.32.1.0 is directly connected, FastEthernet0/0 >> >> B 10.64.1.0 [200/0] via 192.168.2.1, 10:58:40 >> >> 192.168.1.0/32 is subnetted, 1 subnets >> >> O 192.168.1.1 [110/2] via 10.32.1.1, 10:59:25, FastEthernet0/0 >> >> 192.168.2.0/32 is subnetted, 1 subnets >> >> B 192.168.2.2 [200/2] via 192.168.2.1, 10:58:40 >> >> >> >> R1Core#show mpls forwarding-table >> >> Local Outgoing Prefix Bytes tag Outgoing Next Hop >> >> tag tag or VC or Tunnel Id switched interface >> >> 16 Untagged 192.168.100.254/32 \ >> >> 0 Se0/0 point2point >> >> 17 16 192.168.100.2/32 0 Se0/0 point2point >> >> 18 Pop tag 192.168.2.0/24 0 Se0/0 point2point >> >> 19 18 172.32.64.0/24 0 Se0/0 point2point >> >> 20 Aggregate 10.32.1.0/24[V] <http://10.32.1.0/24%5BV%5D> 0 >> >> 21 Untagged 192.168.1.1/32[V] <http://192.168.1.1/32%5BV%5D>0 >> Fa0/0 10.32.1.1 >> >> >> >> R2Core: >> >> Sho IP Route >> >> 172.32.0.0/24 is subnetted, 2 subnets >> >> O IA 172.32.32.0 [110/129] via 192.168.2.254, 11:02:18, Serial0/0 >> >> C 172.32.64.0 is directly connected, FastEthernet0/1 >> >> O 192.168.1.0/24 [110/128] via 192.168.2.254, 11:02:28, Serial0/0 >> >> C 192.168.2.0/24 is directly connected, Serial0/0 >> >> 192.168.100.0/24 is variably subnetted, 3 subnets, 2 masks >> >> C 192.168.100.0/24 is directly connected, Loopback0 >> >> O 192.168.100.1/32 [110/129] via 192.168.2.254, 11:02:19, Serial0/0 >> >> O 192.168.100.254/32 [110/65 <http://192.168.100.254/32%5B110/65>] >> via 192.168.2.254, 11:02:29, Serial0/0 >> >> >> >> Sho ip route vrf BRAD >> >> 10.0.0.0/24 is subnetted, 2 subnets >> >> B 10.32.1.0 [200/0] via 192.168.1.1, 11:02:24 >> >> C 10.64.1.0 is directly connected, FastEthernet0/0 >> >> 192.168.1.0/32 is subnetted, 1 subnets >> >> B 192.168.1.1 [200/2] via 192.168.1.1, 11:02:25 >> >> 192.168.2.0/32 is subnetted, 1 subnets >> >> O 192.168.2.2 [110/2] via 10.64.1.1, 11:03:41, FastEthernet0/0 >> >> >> >> R2Core#sho mpls forwarding-table >> >> Local Outgoing Prefix Bytes tag Outgoing Next Hop >> >> tag tag or VC or Tunnel Id switched interface >> >> 16 Untagged 192.168.100.254/32 \ >> >> 0 Se0/0 point2point >> >> 18 Pop tag 192.168.1.0/24 0 Se0/0 point2point >> >> 19 17 192.168.100.1/32 0 Se0/0 point2point >> >> 20 19 172.32.32.0/24 0 Se0/0 point2point >> >> 21 Aggregate 10.64.1.0/24[V] <http://10.64.1.0/24%5BV%5D> 0 >> >> 22 Untagged 192.168.2.2/32[V] <http://192.168.2.2/32%5BV%5D>0 >> Fa0/0 10.64.1.1 >> >> >> >> R2 >> >> Sho ip route >> >> 10.0.0.0/24 is subnetted, 2 subnets >> >> O E2 10.32.1.0 [110/1] via 10.64.1.254, 11:04:20, FastEthernet0/0 >> >> C 10.64.1.0 is directly connected, FastEthernet0/0 >> >> 192.168.1.0/32 is subnetted, 1 subnets >> >> O E2 192.168.1.1 [110/2] via 10.64.1.254, 11:04:20, FastEthernet0/0 >> >> C 192.168.2.0/24 is directly connected, Loopback0 >> >> >> >> *From:* Joe Astorino [mailto:[email protected]] >> *Sent:* Saturday, November 21, 2009 6:08 AM >> *To:* Solomon Ayele >> *Cc:* [email protected]; Brad Edgeworth >> *Subject:* Re: [OSL | CCIE_RS] Need help with L3 MPLS >> >> >> >> Bryan is right...peer with your loopbacks or the PHP process will happen >> too soon and you will run into issues. If you are doing this over >> frame-relay make sure your frame-relay is running point-to-multipoint as >> well. Also make sure your OSPF is advertising in the actual mask of your >> loopback interfaces (may require ip ospf network point-to-point if you have >> anything other than /32). >> >> Also like Bryan said, the P router need not run BGP ...that is part of the >> glory of this technology. It just needs to have labels to the BGP exit >> points (needs labels for the PE routers loopbacks) and can simply do tag >> switching. >> >> On Sat, Nov 21, 2009 at 3:15 AM, Solomon Ayele <[email protected]> wrote: >> >> >> >> >> >> Hi Brad, >> >> As it can be seen your VPNV4 peering is like this R1Core (PE) <– >> >CoreCentral <– >R2Core (PE). >> >> Therefore R1 has a peering to Core with iBGP and VPNV4 is activated. Good >> R1 has a knowledge of VRF and it can import and export the respective VPNV4 >> addresses to vrf but that is not true for Rcore. >> >> >> >> The other thing is the core has a iBGP peerings with both routers so it >> will not pass the route that it got from one to another. Even if you can >> solve this issue with route reflector or confederation, you have to work >> around to get the VPNV4 traffic around. May be you have to configure the >> Core with vrf .... >> >> >> >> The best way is to peer the two PE routers directly. >> >> The other thing is it is not a must to peer with loopbacks >> >> >> >> Best Regards, >> >> >> >> Solomon >> >> >> >> >> ------------------------------ >> >> *From:* Brad Edgeworth <[email protected]> >> *To:* "[email protected]" <[email protected]> >> *Sent:* Sat, November 21, 2009 8:48:52 AM >> *Subject:* [OSL | CCIE_RS] Need help with L3 MPLS >> >> >> >> So I’m trying to practice MPLS L3 VPN with routing OSPF across it. I’m >> having difficulties with my connectivity from one CE device to the other CE >> device. Before I started I had plain MPLS working on a flat network end to >> end. I’m successful with getting my OSPF routes across the cloud but need >> help figuring out why packets won’t travel. Can someone find what I’m >> missing? >> >> >> >> -brad >> >> >> >> >> >> >> >> Setup is straightforward: R1 (CE) – R1Core (PE) – CoreCentral – R2Core >> (PE) – R2 (CE) >> 10.x.x.x >> subnets are data networks for the CE >> >> >> 192.168.x.x subnets are the provider network >> >> >> >> Routing portion of the configs listed below: >> >> >> >> **R1Core >> >> router ospf 100 vrf BRAD >> >> domain-id 0.0.0.1 >> >> log-adjacency-changes >> >> redistribute bgp 100 subnets >> >> network 10.32.0.0 0.0.255.255 area 1 >> >> router ospf 1 >> >> log-adjacency-changes >> >> network 172.0.0.0 0.255.255.255 area 1 >> >> network 192.168.0.0 0.0.255.255 area 0 >> >> router bgp 100 >> >> no bgp default ipv4-unicast >> >> bgp log-neighbor-changes >> >> neighbor 192.168.1.254 remote-as 100 >> >> ! >> >> address-family vpnv4 >> >> neighbor 192.168.1.254 activate >> >> neighbor 192.168.1.254 send-community both >> >> exit-address-family >> >> ! >> >> address-family ipv4 vrf BRAD >> >> redistribute connected >> >> redistribute ospf 100 vrf BRAD >> >> no synchronization >> >> exit-address-family >> >> >> >> >> >> **** CoreCentral >> >> router ospf 1 >> >> mpls ldp autoconfig >> >> log-adjacency-changes >> >> network 0.0.0.0 255.255.255.255 area 0 >> >> router bgp 100 >> >> no bgp default ipv4-unicast >> >> bgp log-neighbor-changes >> >> neighbor 192.168.1.1 remote-as 100 >> >> neighbor 192.168.2.1 remote-as 100 >> >> ! >> >> address-family vpnv4 >> >> neighbor 192.168.1.1 activate >> >> neighbor 192.168.1.1 send-community extended >> >> neighbor 192.168.1.1 route-reflector-client >> >> neighbor 192.168.2.1 activate >> >> neighbor 192.168.2.1 send-community extended >> >> neighbor 192.168.2.1 route-reflector-client >> >> exit-address-family >> >> >> >> >> >> **R2Core >> >> router ospf 100 vrf BRAD >> >> domain-id 0.0.0.2 >> >> log-adjacency-changes >> >> redistribute bgp 100 subnets >> >> network 10.64.0.0 0.0.255.255 area 2 >> >> router ospf 1 >> >> log-adjacency-changes >> >> network 172.0.0.0 0.255.255.255 area 2 >> >> network 192.168.0.0 0.0.255.255 area 0 >> >> router bgp 100 >> >> no bgp default ipv4-unicast >> >> bgp log-neighbor-changes >> >> neighbor 192.168.2.254 remote-as 100 >> >> ! >> >> address-family vpnv4 >> >> neighbor 192.168.2.254 activate >> >> neighbor 192.168.2.254 send-community both >> >> exit-address-family >> >> ! >> >> address-family ipv4 vrf BRAD >> >> redistribute connected >> >> redistribute ospf 100 vrf BRAD >> >> no synchronization >> >> exit-address-family >> >> >> >> >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> >> >> >> -- >> Regards, >> >> Joe Astorino CCIE #24347 (R&S) >> Sr. Technical Instructor - IPexpert >> Mailto: [email protected] >> Telephone: +1.810.326.1444 >> Live Assistance, Please visit: www.ipexpert.com/chat >> eFax: +1.810.454.0130 >> >> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA >> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & >> Service Provider) Certification Training with locations throughout the >> United States, Europe and Australia. Be sure to check out our online >> communities at www.ipexpert.com/communities and our public website at >> www.ipexpert.com >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > > > -- > Bryan Bartik > CCIE #23707 (R&S, SP), CCNP > Sr. Support Engineer - IPexpert, Inc. > URL: http://www.IPexpert.com > -- Bryan Bartik CCIE #23707 (R&S, SP), CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
