Clarification regarding BGP address family roles in L3VPN

From: John Neiberger <jneiberger_at_gmail.com>
Date: Sat, 5 Jan 2013 16:17:58 -0700

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
Received on Sat Jan 05 2013 - 16:17:58 ART

This archive was generated by hypermail 2.2.0 : Sun Feb 03 2013 - 16:27:17 ART