Re: MPLS VRF - Lite and Ideas

Right on Andrew. Good luck :)

On Mon, Sep 21, 2009 at 9:41 PM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:

> Bryan, you rock man. Many thanks for helping out so much.
>
> Team - I think I got this covered now ... thanks to all, Piotr and Joe,
> many thanks.
>
> VRF Lite by itself if not that interesting ... ok, add some VRFs, and then
> add interfaces etc ... boring.
>
> If anyone is trying to study this, I would encourage you all to add a
> couple of items to your studies and ensure you make this work.
>
> 1) Provide internet access to this VRF Lite configs. In your labs, define
> a router as an internet router and make sure your VRF Lite configs allow for
> a default route to be populated and access to this internet router. It
> really helps to see the big picture.
>
> 2) Make sure the VRF can selectively access global resources. So, as
> before, create a VRF and make sure it has access to an internet simulated
> connection. Then, make sure it can selectively get to a few global routes /
> resources.
>
> In my lab, I leaked a couple of remote global loopback addresses into the
> VRF. I then made sure any router within the VRF can telnet and ping these
> global address.
>
> VRF Lite by itself is boring, but make sure this VRF functions within the
> larger network and you will be challenged and will learn a lot. I did ... I
> was soooo big time stumped at times. I googled a bunch, and of course Bryan
> was a huge help in offering me some good info and advice.
>
> Take care team, and have a great night,
>
> Andrew
>
>
>
> On Fri, Sep 18, 2009 at 9:24 AM, ALL From_NJ <all.from.nj_at_gmail.com>wrote:
>
>> Got started on this tonight ... and it is now 2AM ... I need to let it go
>> for the night. Here is the new topology:
>>
>> R1 (access to the internet and the rest of enterprise)
>> |
>> R5 (configured for vrf lite)
>> |
>> R4 and R6 are each in their own VRF.
>>
>> I have gotten partial connectivity, but the rest of the world does not and
>> cannot get to the two vrfs that I segmented off of R5. I keep thinking I am
>> missing something simple ... oh well. I have tried to look over some docs
>> ... but to no avail.
>>
>> It is very easy to create a segmented network w/ VRF lite. But how to
>> link this with the rest of the world? I have yet to see a working config
>> where vrf lite is linked to the regular network. Everything seems to show
>> separate links throughout the network and keeping the vrfs separate. No
>> magic there ... just simple segmentation.
>>
>> Sorry team, I do not have any configs for you all and or outputs to show.
>> I will pick this up again tomorrow.
>>
>> I am an eager listener in case you all have some advice or have also
>> labbed this up and are able to link vrf lite to the rest of the network.
>> ;-))
>>
>> Have a good night,
>>
>> Andrew
>>
>> On Wed, Sep 16, 2009 at 10:25 PM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>
>> Not sure if that's the best topology (route leaking to global table) to
>>> learn it...but tell us what you find :-) Piotr had a pretty simple but good
>>> explanation. VRF-lite is usually just a part of the picture in a bigger
>>> topology...
>>>
>>>
>>> On Wed, Sep 16, 2009 at 10:09 AM, ALL From_NJ <all.from.nj_at_gmail.com>wrote:
>>>
>>>> Ok, I think I got it, thanks everyone. I will lab this up. Here is my
>>>> topology:
>>>>
>>>> R1 - (Internet simulated) - R5 to R4 and R8. (R2 and R3 are sitting off
>>>> of the internet as well ...)
>>>>
>>>> R5 will have VRF lite to each R4 and R8. R4 and R8 will have unique
>>>> and then overlapping addresses.
>>>>
>>>> Will try and route traffic from R1 to R4/R8.
>>>>
>>>> On R5, I need to allow routes from R4 and R8 into global routing table
>>>> so I can advertise reachability to the 'internet' and ofcourse R1'. I
>>>> suppose static will also work just fine ... so perhaps I will start with
>>>> advertising statics into my global table and then move on to RIP and OSPF.
>>>>
>>>> Can I assume the absense of route targets makes this possible? Normally
>>>> I would control routing updates via route targets ... here I do not have
>>>> any.
>>>>
>>>> Can you all comment on my test topology? Think this is a good lab for
>>>> me to test and learn theory / configs?
>>>>
>>>> Many TIA,
>>>>
>>>> Andrew
>>>>
>>>>
>>>>
>>>> On Wed, Sep 16, 2009 at 10:55 AM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>>>
>>>>> Al,
>>>>>
>>>>> In VRF-lite, links connected to the customer belong to a VRF, and then
>>>>> you have an uplink (connected to PE or other device) for each customer in
>>>>> the same VRF. The segmentation in VRF-lite is really locally significant.
>>>>> It's the design that makes it useful to segment traffic across the network.
>>>>>
>>>>> Also, there is no need for a label in a VRF-lite scenario. Labeling is
>>>>> needed is when you have a device that is forwarding based on something other
>>>>> than destination IP address (e.g. in MPLS VPN, forwarding in a P-cloud is
>>>>> based on the egress PE's address so a label is needed). In this case the CE
>>>>> (or router doing VRF-lite) is still using the destination IP to make its
>>>>> decision, so it does not need any label.
>>>>>
>>>>> -hth
>>>>>
>>>>>
>>>>> On Tue, Sep 15, 2009 at 10:04 PM, ALL From_NJ <all.from.nj_at_gmail.com>wrote:
>>>>>
>>>>>> Many thanks for this. Ok, simple enough ... I appreciate you both
>>>>>> writing
>>>>>> such a good post.
>>>>>>
>>>>>> Question though related to internet access and multiple sites.
>>>>>>
>>>>>> Lets say we have R1 and R2, just as you have them above. How does
>>>>>> each
>>>>>> router know to keep traffic for each VRF? I do not see labels being
>>>>>> used in
>>>>>> the configs you provide ...
>>>>>>
>>>>>> It appears that VRF lite requires dedicated links for forwarding and
>>>>>> keeping
>>>>>> the route updates separate.
>>>>>>
>>>>>> I know I am mixing technologies here with this next question, but just
>>>>>> curious about this ...
>>>>>>
>>>>>> When I have a CE and have segmented multiple customers off of this CE,
>>>>>> how
>>>>>> does the uplink / PE know which traffic goes to and from each customer
>>>>>> VRF?
>>>>>> I need to inform the PE of which routes to send to the CE and to which
>>>>>> VRF
>>>>>> ... perhaps this is not possible w/ VRF lite.
>>>>>>
>>>>>> Joe - I would imagine that VRF Lite works well with dot1x sub
>>>>>> interfaces.
>>>>>>
>>>>>> The link I found previously, was somewhat of a mix of regular MPLS
>>>>>> VPNS, and
>>>>>> CSC ... where the CSC configs required the sending of labels, and
>>>>>> treated
>>>>>> this CE device like a customer PE
>>>>>>
>>>>>> Understand my confusion when I was reading this? ;-)
>>>>>>
>>>>>> VRF lite reminds me a little of private VLANs ... these are similar
>>>>>> IMO.
>>>>>> Although ... w/ VRF lite, I do not see the configuration of a
>>>>>> promiscuous
>>>>>> port ... how to uplink multiple customer VRFs?
>>>>>>
>>>>>> Also, on a side note, this would be an odd thing to add to the lab IMO
>>>>>> ...
>>>>>>
>>>>>> Many TIA,
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 15, 2009 at 4:37 PM, Joe Astorino <jastorino_at_ipexpert.com
>>>>>> >wrote:
>>>>>>
>>>>>> > The way I understand it, VRF-Lite is basically VRFs but without the
>>>>>> BGP to
>>>>>> > transport the routes. Also, there seems to be a stressing of using
>>>>>> switches
>>>>>> > to trunk to router sub-interfaces for different VRFs.
>>>>>> >
>>>>>> >
>>>>>> > On Tue, Sep 15, 2009 at 4:28 PM, Piotr Matusiak <piotr_at_ccie1.com>
>>>>>> wrote:
>>>>>> >
>>>>>> >> Hi,
>>>>>> >>
>>>>>> >> Believe me or not, but for me VRF lite is only 3-commands feature:
>>>>>> >> #ip vrf <name>
>>>>>> >> #rd <asn:nn>
>>>>>> >> #ip vrf forwarding <name>
>>>>>> >>
>>>>>> >> Rest of commands only support prefixes delivery in my opinion.
>>>>>> >> Take a look at the following config and decide if this is VRF Lite
>>>>>> or not
>>>>>> >> :)
>>>>>> >>
>>>>>> >> Topo: R1 ==== R2 (two links, each in separate VRF)
>>>>>> >>
>>>>>> >> R1 config:
>>>>>> >>
>>>>>> >> ip vrf CUST1
>>>>>> >> rd 1:1
>>>>>> >> !
>>>>>> >> ip vrf CUST2
>>>>>> >> rd 2:2
>>>>>> >>
>>>>>> >> interface Loopback0
>>>>>> >> ip vrf forwarding CUST1
>>>>>> >> ip address 1.1.1.1 255.255.255.0
>>>>>> >> !
>>>>>> >> interface Loopback1
>>>>>> >> ip vrf forwarding CUST2
>>>>>> >> ip address 11.11.11.11 255.255.255.0
>>>>>> >> !
>>>>>> >> interface FastEthernet0/0
>>>>>> >> ip vrf forwarding CUST1
>>>>>> >> ip address 10.1.12.1 255.255.255.0
>>>>>> >> !
>>>>>> >> interface FastEthernet0/1
>>>>>> >> ip vrf forwarding CUST2
>>>>>> >> ip address 10.1.21.1 255.255.255.0
>>>>>> >> !
>>>>>> >> router rip
>>>>>> >> version 2
>>>>>> >> no auto-summary
>>>>>> >> !
>>>>>> >> address-family ipv4 vrf CUST2
>>>>>> >> network 10.0.0.0
>>>>>> >> network 11.0.0.0
>>>>>> >> no auto-summary
>>>>>> >> exit-address-family
>>>>>> >> !
>>>>>> >> address-family ipv4 vrf CUST1
>>>>>> >> network 1.0.0.0
>>>>>> >> network 10.0.0.0
>>>>>> >> no auto-summary
>>>>>> >> exit-address-family
>>>>>> >> !
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> R2 config:
>>>>>> >>
>>>>>> >> ip vrf CUST1
>>>>>> >> rd 1:1
>>>>>> >> !
>>>>>> >> ip vrf CUST2
>>>>>> >> rd 2:2
>>>>>> >> !
>>>>>> >> interface Loopback0
>>>>>> >> ip vrf forwarding CUST1
>>>>>> >> ip address 2.2.2.2 255.255.255.0
>>>>>> >> !
>>>>>> >> interface Loopback1
>>>>>> >> ip vrf forwarding CUST2
>>>>>> >> ip address 22.22.22.22 255.255.255.0
>>>>>> >> !
>>>>>> >> interface FastEthernet0/0
>>>>>> >> ip vrf forwarding CUST1
>>>>>> >> ip address 10.1.12.2 255.255.255.0
>>>>>> >> !
>>>>>> >> interface FastEthernet0/1
>>>>>> >> ip vrf forwarding CUST2
>>>>>> >> ip address 10.1.21.2 255.255.255.0
>>>>>> >> !
>>>>>> >> router rip
>>>>>> >> version 2
>>>>>> >> no auto-summary
>>>>>> >> !
>>>>>> >> address-family ipv4 vrf CUST2
>>>>>> >> network 10.0.0.0
>>>>>> >> network 22.0.0.0
>>>>>> >> no auto-summary
>>>>>> >> exit-address-family
>>>>>> >> !
>>>>>> >> address-family ipv4 vrf CUST1
>>>>>> >> network 2.0.0.0
>>>>>> >> network 10.0.0.0
>>>>>> >> no auto-summary
>>>>>> >> exit-address-family
>>>>>> >>
>>>>>> >>
>>>>>> >> TEST:
>>>>>> >>
>>>>>> >> R1#sh ip ro vrf CUST1 rip
>>>>>> >> 2.0.0.0/24 is subnetted, 1 subnets
>>>>>> >> R 2.2.2.0 [120/1] via 10.1.12.2, 00:00:09, FastEthernet0/0
>>>>>> >> R1#
>>>>>> >>
>>>>>> >> R1#sh ip ro vrf CUST2 rip
>>>>>> >> 22.0.0.0/24 is subnetted, 1 subnets
>>>>>> >> R 22.22.22.0 [120/1] via 10.1.21.2, 00:00:06, FastEthernet0/1
>>>>>> >>
>>>>>> >> R1#ping vrf CUST2 22.22.22.22 so lo1
>>>>>> >>
>>>>>> >> Type escape sequence to abort.
>>>>>> >> Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2
>>>>>> seconds:
>>>>>> >> Packet sent with a source address of 11.11.11.11
>>>>>> >> !!!!!
>>>>>> >> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/20/44
>>>>>> ms
>>>>>> >> R1#
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Piotr Matusiak
>>>>>> >> CCIE #19860 (R&S, SEC)
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> 2009/9/15 ALL From_NJ <all.from.nj_at_gmail.com>:
>>>>>> >> > Hey folk,
>>>>>> >> >
>>>>>> >> > I have not done vrf lite before ... and I found some docs related
>>>>>> to
>>>>>> >> mpls
>>>>>> >> > lite, but am not able to find much on the doc cd. Here is what I
>>>>>> found:
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> http://www.cisco.com/en/US/docs/ios/12_2sb/12_2sba/feature/guide/vrflite.html
>>>>>> >> >
>>>>>> >> > Any better links than the one above? This seems to be a bit
>>>>>> dated and
>>>>>> >> not
>>>>>> >> > all the commands work ...
>>>>>> >> >
>>>>>> >> > Notes on VRF Lite:
>>>>>> >> > - VRF Lite appears to be plain MPLS VPNs configured, with the
>>>>>> send-label
>>>>>> >> > command on the PEs, and MPLS configured between PE and CE. Any
>>>>>> other
>>>>>> >> > throughts?
>>>>>> >> >
>>>>>> >> > Also, I am looking for some additional lab ideas on MPLS VPNs ...
>>>>>> >> > configuring them is not too hard, and tshooting my own screwups
>>>>>> has been
>>>>>> >> > entertaining. I am looking for some ideas on ways to make this
>>>>>> better.
>>>>>> >> >
>>>>>> >> > The config examples are pretty easy to follow in case e get hung
>>>>>> up on a
>>>>>> >> > task ...
>>>>>> >> >
>>>>>> >>
>>>>>> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_cfg_layer3_vpn_ps6350_TSD_Products_Configuration_Guide_Chapter.html
>>>>>> >> >
>>>>>> >> > Many TIA,
>>>>>> >> >
>>>>>> >> > --
>>>>>> >> > Andrew Lee Lissitz
>>>>>> >> > all.from.nj_at_gmail.com
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Blogs and organic groups at http://www.ccie.net
>>>>>> >> >
>>>>>> >> >
>>>>>> _______________________________________________________________________
>>>>>> >> > Subscription information may be found at:
>>>>>> >> > http://www.groupstudy.com/list/CCIELab.html
>>>>>> >>
>>>>>> >>
>>>>>> >> Blogs and organic groups at http://www.ccie.net
>>>>>> >>
>>>>>> >>
>>>>>> _______________________________________________________________________
>>>>>> >> Subscription information may be found at:
>>>>>> >> http://www.groupstudy.com/list/CCIELab.html
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Regards,
>>>>>> >
>>>>>> > Joe Astorino - CCIE #24347 R&S
>>>>>> > Technical Instructor - IPexpert, Inc.
>>>>>> > Cell: +1.586.212.6107
>>>>>> > Fax: +1.810.454.0130
>>>>>> > Mailto: jastorino_at_ipexpert.com
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Andrew Lee Lissitz
>>>>>> all.from.nj_at_gmail.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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Andrew Lee Lissitz
>>>> all.from.nj_at_gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Bryan Bartik
>>> CCIE #23707 (R&S), CCNP
>>> Sr. Support Engineer - IPexpert, Inc.
>>> URL: http://www.IPexpert.com
>>>
>>
>>
>>
>> --
>> Andrew Lee Lissitz
>> all.from.nj_at_gmail.com
>>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>

-- 
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