Re: Clarification regarding BGP address family roles in L3VPN

Yes, exactly.

-Yuri

On Sat, Jan 5, 2013 at 9:08 PM, John Neiberger <jneiberger_at_gmail.com> wrote:

> Thanks Yuri! That's exactly what I was misunderstanding. Someone replied
> to me off-list, as well, and set me straight.
>
> So, in this design, I don't need a peer configured in the vrf AF because
> I'm not using BGP to the CE, but I still need to configure the AF with
> redistribution to get the routes into BGP to begin with. Once the routes
> are in BGP, the route targets control which routes are exported. And
> correct me if I'm wrong, but if I were using LDP and IGP, I also wouldn't
> need to configure the plain ipv4 AF, either, because the only reason it
> exists in this configuration is to allocate and advertise labels.
>
> Does that sound about right?
>
> Thanks again,
> John
>
>
> On Sat, Jan 5, 2013 at 8:44 PM, Yuri Bank <yuribank_at_gmail.com> wrote:
>
>>
>> As you mentioned, the VPNv4 address family is what actually sends the
>> customer prefix information along with RD and RT values to the remote PE.
>> But you need the 'address-family ipv4 vrf A' section and the
>> redistribution statement so that you can bring the vrf routes into BGP to
>> begin with! The import & export statements (under vrf config) only specify
>> which route-targets to bring into the VRF table, and which route-targets to
>> use when a route from that VRF is brought into BGP. The export statement
>> does not unconditionally bring a route into BGP, you must still
>> redistribute/use network statements/or run BGP with the customer, to have
>> the route in your BGP table.
>>
>> The 'neighbor' statement under ' address-family ipv4 vrf A' is
>> completely unnecessary in your situation since you aren't running BGP with
>> the CE.
>>
>> To summarize:
>>
>> When a VPNv4 route is learned from a remote PE, the route-targets
>> included in the extended community are matched against your VRFs import
>> statements. If there is a match, that route is brought into the RIB for
>> that VRF.
>> When a route is learned from a CE, the route will be in the RIB for that
>> VRF, but will not get advertised as a VPNv4 route unless it is
>> redistributed into BGP.
>>
>>
>> -Yuri
>>
>>
>>
>>
>>
>> On Sat, Jan 5, 2013 at 3:17 PM, John Neiberger <jneiberger_at_gmail.com>wrote:
>>
>>> This is a bit long and rambling, so I apologize ahead of time and fully
>>> understand if you get about halfway through and stop reading. :-)
>>>
>>> Based on a problem someone else was having on a different list, I thought
>>> I'd lab this up and see what I could make of it. It's basically an
>>> attempt
>>> at simple Inter-AS L3VPN. I was eventually able to get it working, but it
>>> led to some questions about the role of the various address families in
>>> this configuration. I had the following simple topology:
>>>
>>> [R1]----[R2]-----[R3]-----[R4]
>>>
>>> R1 and R4 and CE, while R2 and R3 are PE. I'm not running LDP, nor am I
>>> running an IGP. I'm using BGP+label on the R2-R3 link. RIP is my PE-CE
>>> protocol.
>>>
>>> Here is the working BGP config on R2:
>>>
>>> router bgp 2
>>> bgp log-neighbor-changes
>>> neighbor 10.2.3.3 remote-as 3
>>> !
>>> address-family ipv4
>>> neighbor 10.2.3.3 activate
>>> neighbor 10.2.3.3 send-label
>>> no auto-summary
>>> no synchronization
>>> exit-address-family
>>> !
>>> address-family vpnv4
>>> neighbor 10.2.3.3 activate
>>> neighbor 10.2.3.3 send-community both
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf A
>>> redistribute rip metric 1
>>> neighbor 10.2.3.3 remote-as 3
>>> neighbor 10.2.3.3 activate
>>> no synchronization
>>> exit-address-family
>>>
>>> In order for me to get this to work, all three address families had to be
>>> configured and I'm not exactly sure why. I'll explain the process I went
>>> through to make it work so you'll understand the questions I'm asking.
>>>
>>> I began with only the IPv4 address family and had it configured to
>>> redistribute RIP and send labels. That wasn't working and it occurred to
>>> me
>>> that I needed to be using VPNv4 because I have VRFs present, so VPNv4
>>> information needs to pass between the PEs so they know what to do with
>>> the
>>> routes.
>>>
>>> So, I added the VPNv4 address family. That alone didn't work until I
>>> realized that I wasn't sending extended communities. I fixed that and
>>> this
>>> still wasn't working. R2 was not redistributing my RIP customer routes
>>> into
>>> BGP yet.
>>>
>>> Next, I added the "address-family ipv4 vrf A" and configured it to
>>> redistribute RIP as you can see above. Once I did this on both PEs, I was
>>> able to ping successfully between CE routers.
>>>
>>> I thought maybe I didn't really need the regular address-family ipv4, so
>>> I
>>> removed it and added "neighbor 10.2.3.3 send-label" to the ipv4 vrf A
>>> address family. This did not work, and I was not able to figure out why.
>>> The VPNv4 table on R3 was the same either way, as was the mpls forwarding
>>> table. However, if I looked specifically at the route for 10.1.1.1/32,
>>> the
>>> loopback on R1, it said "no best route". There clearly was a reachability
>>> issue somewhere, but I couldn't find a command that would show me exactly
>>> what was happening.
>>>
>>> I then changed it back to the way it was, the way you see above, and it's
>>> back to working.
>>>
>>> So, my questions are these:
>>>
>>> 1. Why do I need the ipv4 vrf A address family? As I understand it, the
>>> global ipv4 address family is needed for label origination and the vpnv4
>>> AF
>>> is needed to send the VPNv4 routes learned from the vrf. So why do I need
>>> yet another AF to make this work? What is the ipv4 vrf A address family
>>> actually doing under the hood?
>>>
>>> 2. Why do I need to redistribute RIP routes into the ipv4 vrf A address
>>> family? As I understand it, the goal is to send VPN routes from PE to PE,
>>> and those are already in the VPNv4 address family. I believe that no
>>> redistribution statement is required because the import and export route
>>> targets handle that with VPNv4 routes, right? Why do I need to configure
>>> yet another AF and redistribute RIP routes into it? What does that do for
>>> me?
>>>
>>> I know that each AF serves a specific purpose in this configuration, but
>>> I'm still a little confused by them. I was able to get this working,
>>> which
>>> was pretty amazing, but I clearly have a gap in understanding that I'd
>>> like
>>> to fill.
>>>
>>> Thanks!
>>> John
>>>
>>>
>>> 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
Received on Sun Jan 06 2013 - 00:37:12 ART