Re: VRF - VPN4 Problem

Dear victor

 Thank you for your troubleshooting steps which are very useful indeed ,

However I am still having the same problem . I recognized that site 1 in sp
1 can see the routers of site 2 in sp2 .

In PE of sp1 , Sh ip route vrf ABC , show all the sp2 CE routes

Sh ip bgp vpn4 all in SP1 show all the SP2 CE routes

However s h ip cef vrf ABC 10.10.1.1 which is a prefix of CE 2

Will show the routes but no VPN tages

R6 and R9 are the PE connected by frame relay

the question for all .... What makes the routes to not show in the cef table
? ????

R6 ) sh ip cef vrf ABC 10.10.1.1

10.10.1.1/32, version 25, epoch 0, cached adjacency 10.10.69.9

0 packets, 0 bytes

  tag information set

    local tag: VPN-route-head

  via 10.10.69.9, 0 dependencies, recursive

    next hop 10.10.69.9, Serial2/0 via 10.10.69.9/32

    valid cached adjacency

On Mon, Jun 22, 2009 at 11:10 PM, Victor Cappuccio <vcappuccio_at_gmail.com>wrote:

> Hi,
>
> Before you start MPLS VPN troubleshooting, you should ask the following
> questions:
>
> 1.- Is Cisco Express Forwarding (CEF) enabled on all routers in the transit
> path between the provider edge (PE) routers?
>
> You can verify the validity of the CEF entry and the associated label stack
> with the show ip cef vrf vrf-name ip-prefix detail command. The top label in
> the stack should correspond to the BGP next-hop label as displayed by the
> show mpls forwarding-table command on the ingress router. The second label
> in the stack should correspond to the label allocated by the egress router.
>
>
> 2.- Are labels for Border Gateway Protocol (BGP) next hops generated and
> propagated?
> 3.- Are there any maximum transmission unit (MTU) issues in the transit
> path ?
> 4.- Verifying the routing information flow using the checks outlined in the
> figure
> 5.- Verifying the data flow, or packet forwarding
> 6.- Are you including the vrf interface into the MP-BGP process??
>
> The first step is to check the routing information exchange from CE routers
> to PE routers. you can use the show ip route vrf vrf-name command to verify
> that the PE router receives customer routes from the CE router.
>
> The CE routes received by the PE router need to be redistributed into
> Multiprotocol BGP (MP BGP); if you do not do this, the routes will not get
> propagated to other PE routers.
>
> The CE routes redistributed into MP-BGP need to be propagated to other PE
> routers.
>
> Verify the correct route propagation using show ip bgp vpnv4 all ip-prefix
> command on the remote PE router.
>
> Routes sent by the originating PE router might not be received by a remote
> PE router because of automatic RT-based filters installed on the remote PE
> router.
>
> Automatic route filters are based on RTs. Verify that the RTs attached to
> the CE route in the originating PE router match at least one of the RTs
> configured as import RTs in the VRF on the receiving PE router.
>
> The VPN version 4 (VPNv4) routes received by the PE router have to be
> inserted into the proper VRF. This insertion can be verified with the show
> ip route vrf command.
>
> the BGP routes received via MP-BGP and inserted into the VRF need to be
> redistributed into the PE-CE routing protocol. A number of common
> redistribution mistakes can occur here, starting with missing redistribution
> metrics.
>
> The routes redistributed into the PE-CE routing protocol have to be
> propagated to CE routers. You may also configure the CE routers with a
> default route toward the PE routers.
>
>
> On Mon, Jun 22, 2009 at 9:36 PM, Dayaa Al Zoubi <cciecool_at_gmail.com>wrote:
>
>> hi
>> two different bgp areas means two different sp , the VPN4
>> connectivity
>> between them , in the border router sh ip route will not show the customer
>> routes , sh ip bgp vpn4 all will show , but when pinging from the customer
>> vrf in sp 1 to vrf in sp2 the border and debug the ip packet in the
>> border
>> router , it the destination unroutable !!!!!
>> so the destination not in the routing table but in the vpn4 table and the
>> router not checking this table !!!!
>> why is that ......
>>
>> thansk
>> dayaa
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Victor Cappuccio
> CCIE R/S# 20657
> CCSI# 30452
> www.anetworkerblog.com
> www.linkedin.com/in/vcappuccio

Blogs and organic groups at http://www.ccie.net
Received on Tue Jun 23 2009 - 17:28:16 ART