Re: Clarification regarding BGP address family roles in L3VPN

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 Sat Jan 05 2013 - 22:08:17 ART