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 - 19:44:04 ART
This archive was generated by hypermail 2.2.0 : Sun Feb 03 2013 - 16:27:17 ART