Re: mpls vpn route-target

Yes, if I put import also on R3 it works. But now I'm confused how
come that it works when you just put this on R4 (like solution of the
task specifies):

ip vrf VPNB
   route-target both 1:105

??

On Mon, Nov 2, 2009 at 8:30 PM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:
> Ivan,
>
> Yes definitely, R3 needs the import statement. VRFs are really locally
> significant. The only thing that allows them to communicate is the use of
> RTs.
>
> On Mon, Nov 2, 2009 at 12:17 PM, Ivan <ivanzghr_at_gmail.com> wrote:
>>
>> R1 is getting updates from other side, which means it is configured
>> correctly:
>>
>> R1#sh ip ro
>> Gateway of last resort is not set
>>
>> C 1.0.0.0/8 is directly connected, Loopback0
>> D 5.0.0.0/8 [90/2809856] via 10.1.13.3, 01:03:54, Serial0/1/1
>> 10.0.0.0/24 is subnetted, 2 subnets
>> C 10.1.13.0 is directly connected, Serial0/1/1
>> D 10.1.45.0 [90/2681856] via 10.1.13.3, 01:03:54, Serial0/1/1
>> C 192.168.1.0/24 is directly connected, FastEthernet0/1
>>
>> R5 is getting updates from R1 and exported routes from VPNB (R6):
>> R5#sh ip ro
>> Gateway of last resort is not set
>>
>> D 1.0.0.0/8 [90/2809856] via 10.1.45.4, 01:04:30, Serial0/0/0.54
>> C 5.0.0.0/8 is directly connected, Loopback0
>> D EX 6.0.0.0/8 [170/2560512256] via 10.1.45.4, 00:27:34, Serial0/0/0.54
>> C 192.168.5.0/24 is directly connected, FastEthernet0/0
>> 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
>> D 10.1.13.0/24 [90/2681856] via 10.1.45.4, 01:04:30, Serial0/0/0.54
>> D 10.0.0.0/8 is a summary, 01:09:50, Null0
>> D EX 10.1.46.0/24 [170/2560512256] via 10.1.45.4, 00:32:19,
>> Serial0/0/0.54
>> C 10.1.45.0/24 is directly connected, Serial0/0/0.54
>>
>> R6 is getting routes from VPNA (EIGRP routes)
>>
>> R6#sh ip ro
>> Gateway of last resort is not set
>>
>> O E2 1.0.0.0/8 [110/2297856] via 10.1.46.4, 00:28:57, FastEthernet0/0
>> O E2 5.0.0.0/8 [110/2297856] via 10.1.46.4, 00:28:57, FastEthernet0/0
>> C 6.0.0.0/8 is directly connected, Loopback0
>> 10.0.0.0/24 is subnetted, 3 subnets
>> O E2 10.1.13.0 [110/1] via 10.1.46.4, 00:28:57, FastEthernet0/0
>> C 10.1.46.0 is directly connected, FastEthernet0/0
>> O E2 10.1.45.0 [110/1] via 10.1.46.4, 00:28:57, FastEthernet0/0
>>
>> Only R1 doesn't get VPNB's routes. Is it enought to configure rt
>> import only on one PE router which has defined vrf VPNA or on both PE
>> routers which have vrf VPNA. Now, router R3 doesn't have import
>> configured such as R4 has?
>>
>> On Mon, Nov 2, 2009 at 8:09 PM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:
>> > Ivan,
>> >
>> > Either way will work, just as long as routes that are exported with the
>> > specific RT are being imported in the proper VRFs. Just take care that
>> > you
>> > don't allow reachability to sites that shouldn't have it (which doesn't
>> > seem
>> > like the case here). Also make sure you have a metric when
>> > redistributing
>> > into EIGRP, you know the basics sometimes get skipped :)
>> >
>> > Other than that, post your PE configs and maybe we can spot something...
>> >
>> > On Mon, Nov 2, 2009 at 11:50 AM, Ivan <ivanzghr_at_gmail.com> wrote:
>> >>
>> >> P.S.
>> >> About topology (if someone receives mail and everything is moved :):
>> >> R6 is connected to PE R4...
>> >>
>> >> On Mon, Nov 2, 2009 at 7:47 PM, Ivan <ivanzghr_at_gmail.com> wrote:
>> >> > OK. I have topology like this:
>> >> >
>> >> > R1 -- R3 -- R2 --R4 --R5
>> >> > |
>> >> > R6
>> >> >
>> >> > R1 and R5 are pure customer routers in VPNA, and R6 is customer
>> >> > router
>> >> > in VPNB.
>> >> > R3 and R4 are PE routers and R2 is just P router.
>> >> > R1 and R5 are using EIGRP as routing protocol, and R6 is running
>> >> > OSPF.
>> >> > Everything is redistributed in MP-BGP and vice-versa for every VPN
>> >> > and
>> >> > working OK.
>> >> >
>> >> > Task says that router R6 needs to participate in the same CUG as R1
>> >> > and
>> >> > R5.
>> >> >
>> >> > On R3 I have vrf:
>> >> > !
>> >> > ip vrf VPNA
>> >> > rd 1:20
>> >> > route-target export 1:105
>> >> > route-target import 1:105
>> >> > !
>> >> > on R4 vrf:
>> >> > !
>> >> > ip vrf VPNA
>> >> > rd 1:40
>> >> > route-target both 1:105
>> >> > !
>> >> > ip vrf VPNB
>> >> > rd 1:50
>> >> > route-target both 1:600
>> >> >
>> >> > As I understand RTs, when you say route-target both in some vrf it
>> >> > means that all routes which has this ext BGP community will be
>> >> > exported from vrf into MP-BGP, and imported from MP-BGP into vrf,
>> >> > right?
>> >> >
>> >> > Shouldn't next solution be enough for R1 and R5 to have VPNB's OSPF
>> >> > routes in its routing tables, and R6 to have VPNA's EIGRP routes in
>> >> > its routing table as OSPF E2 routes:
>> >> >
>> >> > ip vrf VPNA
>> >> > rd 1:20
>> >> > route-target export 1:105
>> >> > route-target import 1:105
>> >> > route-target import 1:600 (importing routes that were exported from
>> >> > vrf
>> >> > VPNB)
>> >> >
>> >> > ip vrf VPNB
>> >> > rd 1:50
>> >> > route-target export 1:600
>> >> > route-target import 1:600
>> >> > route-target import 1:105 (importing routes that were exported into
>> >> > MP-BGP from vrf VPNA)
>> >> >
>> >> > ?? After this R6 has all VPNA's routes as E2 routes but R1 doesn't
>> >> > have VPNB's routes as D EX routes ??
>> >> >
>> >> > Solution of the task says just this:
>> >> > ip vrf VPNB
>> >> > route-target both 1:105
>> >> >
>> >> > Some clarification please. Thanks
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >>
>> >> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Bryan Bartik
>> > CCIE #23707 (R&S), CCNP
>> > Sr. Support Engineer - IPexpert, Inc.
>> > URL: http://www.IPexpert.com
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com

Blogs and organic groups at http://www.ccie.net
Received on Mon Nov 02 2009 - 20:54:03 ART