MultiProtocol BGP

tomtom1

Hi,

I've jumped into a SP network in a new role and I'm trying to lab out a part of their network, especially the part where the VRF and BGP routing is being done. Currently, I have the following topology.



What I have configured so far:
-> PPPoE client on R1 and R8, which is working, both get their PPP session and an IP address on the Dialer interface.
-> On R2 I've created 2 VRF, respectively VRF 1 and VRF2. The virtual-template interface belongs to the customer based VRF and both the VT IP address and the IP address the CE get show up as connected in the VRF routing table:

R2#sh ip route vrf 1 connected 
     172.31.0.0/30 is subnetted, 1 subnets
C       172.31.255.0 is directly connected, Virtual-Access1.1
     10.0.0.0/32 is subnetted, 1 subnets
C       10.30.0.254 is directly connected, Virtual-Access1.1

What I'm trying to do is get these routes into the core of the network (R3 & R3) via BGP while maintaining the VRF structure (and thus isolation) between the customers, or is this not how it is normally done? In taking a working configuration I noticed some special configuration in the BGP setup.

[B] address-family vpnv4[/B]

In doing some research, I came across the fact that MP-BGP is able to carry VRF information in the BGP updates. I've configured the VRF's like this:

ip vrf 1
 rd 65535:1
 route-target export 65535:1
 route-target import 65535:1
!
ip vrf 2
 rd 50522:2
 route-target export 65535:2
 route-target import 65535:2

In configuring it like this, I believe I have made the following changes:
RD - For VRF 1 all routes have a community set to 65535:1 to uniquely identify that route in case of overlapping subnets.
RT Export - Export routes with a community set to 65535:1 (export into where?!)
RT Import - Import routes into this VRF with a community set to 65535:1

The BGP config on R2 looks like this:

router bgp 65535
 bgp log-neighbor-changes
 neighbor INTERNAL-PEER peer-group
 neighbor INTERNAL-PEER remote-as 65535
 neighbor 10.255.23.3 peer-group INTERNAL-PEER
 neighbor 10.255.24.4 peer-group INTERNAL-PEER
 !
 address-family ipv4
 neighbor INTERNAL-PEER send-community
 neighbor 10.255.23.3 activate
 neighbor 10.255.24.4 activate
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family vpnv4
 neighbor INTERNAL-PEER send-community extended
 neighbor 10.255.23.3 activate
 neighbor 10.255.24.4 activate
 exit-address-family
 !
 address-family ipv4 vrf 1
 redistribute connected metric 20
 redistribute static metric 20
 no synchronization
 exit-address-family

And like this on R3:

 no synchronization
 bgp log-neighbor-changes
 neighbor INTERNAL-PEER peer-group
 neighbor INTERNAL-PEER remote-as 65535
 neighbor 10.255.23.2 peer-group INTERNAL-PEER
 neighbor 10.255.34.4 peer-group INTERNAL-PEER
 neighbor 10.255.35.2 peer-group INTERNAL-PEER

Obviously, I don't entirely know what I'm doing here but I'm learning as we go. Basically, I have the following questions:

1) When the route-target export command is used, where do the routes go? Into BGP?
2) How can I get the customer routes into the core? Is this best practice for a SP network or does it work another way? A push in the right direction is better than a complete solution.
3) Are there books available that further outline this material? I'm hoping to fully join in preparing for the CCIE via this site one day.

Thanks! There is so much more I need to learn!

lrb

tomtom1 wrote: »

1) When the route-target export command is used, where do the routes go? Into BGP?
2) How can I get the customer routes into the core? Is this best practice for a SP network or does it work another way? A push in the right direction is better than a complete solution.
3) Are there books available that further outline this material? I'm hoping to fully join in preparing for the CCIE via this site one day.

Good initiative on trying to lab up the work network at home, you'll make a good CCIE candidate soon if you keep that kind of drive up . I only skimmed most of your post to see the questions so excuse me if I repeat information you already know.

1) RTs control which routes get imported into a VRF RIB and exported out of a VRF RIB. When you export them into BGP these RTs get attached to to the route as extended communities. On the receiving PE routers (those activated under the VPNv4 AF) they will look for any VRFs that have these export RTs listed as import RTs. When a match is found, the route is imported into the VRF table as a BGP route, with the NEXT_HOP attribute set to the originating PE router most of the time (which is why the IGP/outer label is required). You can create some pretty interesting scenarios with RTs (see my thread about BGP hub and spoke if you are interested in one of them) but they are very flexible, and because they are just extended communities, you can attach multiple export RTs to a route.

And don't forget that there will be lots of customers of a provider, and it is very likely that they will have overlapping internal address spaces so this is where the RD comes in; to keep the routes unique within BGP.

On the receiving PE router you will see something like the following when it has been imported into the C16 VRF. Note the "imported from..." line

[COLOR=#000000][FONT=Courier New]R2#show ip bgp vpnv4 vrf C16 10.0.46.0[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]BGP routing table entry for 16:1:10.0.46.0/24, version 13[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]Paths: (1 available, best #1, table C16)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]Flag: 0x820[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]  Not advertised to any peer[/FONT][/COLOR]
[B]  Local, imported path from 4:6:10.0.46.0/24
[/B][COLOR=#000000][FONT=Courier New]    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]      Origin incomplete, metric 0, localpref 100, valid, internal, best[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]      Extended Community: RT:16:6[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]      mpls labels in/out nolabel/19[/FONT][/COLOR]

2) You generally don't want to do this. One of the benefits of MPLS VPN is that the P routers don't need to run BGP and can simply do hardware label switching of packets rather than have to maintain massive BGP tables. In this case, the P routers can still forward customer traffic because they are simply doing label switching on the IGP/outer MPLS label. In larger networks you may often see some routers in the core take the role of a VPNv4/VPNv6 route reflector in which case the all of the PE routers maintain one or two BGP sessions to the RRs. Nevertheless, if you can keep customer routers out of the core then you are better off.

3) MPLS Fundamentals chapter 7 is your best bet. Alternatively, the INE MPLS course is not too bad either.

fredrikjj

What lrb wrote is correct, but you need to start with MPLS itself or MPLS VPNs won't make sense. In other words, read chapter 1-6 before you read chapter 7 of MPLS Fundamentals.

tomtom1

fredrikjj wrote: »

What lrb wrote is correct, but you need to start with MPLS itself or MPLS VPNs won't make sense. In other words, read chapter 1-6 before you read chapter 7 of MPLS Fundamentals.

Thanks for the replies, both of you. The book is ordered and I hope this will further strengthen my knowledge. So if I understand correctly, MPLS is first enabled on the PE and the SP core only runs MPLS. However, I think the company that I'm working for is doing a V4 / V6 RR as I see route reflector client statements and BGP in the core. So it is possible, right? Just for the sake of argument, how can I achieve this? Or would it be better to start the MPLS book, and work my way through, sinds VRF is basically a subset of MPLS.

fredrikjj

tomtom1 wrote: »

So if I understand correctly, MPLS is first enabled on the PE and the SP core only runs MPLS. However, I think the company that I'm working for is doing a V4 / V6 RR as I see route reflector client statements and BGP in the core. So it is possible, right? Just for the sake of argument, how can I achieve this? Or would it be better to start the MPLS book, and work my way through, sinds VRF is basically a subset of MPLS.

If you want a L3 VPN without MPLS you would have to create VRFs on the core routers and then ensure that these VRF hold the customer prefixes and that the correct packets arrive on the correct interfaces. You could use physical interfaces or subinterfaces. If you don't use VRFs, you would essentially just have a normal core router with a global routing table and that defeats the purpose of a VPN - a customer's traffic shouldn't be forwarded using the same forwarding table as another. Plus, you wouldnt be able to carry overlapping IP prefixes.

About the RRs, as lrb said above, you could use route reflectors to reflect VPNv4 prefixes to routers that need them, but this doesn't mean that customer traffic is IP forwarded.

lrb

VPNv4/v6 RR configuration is just like a normal RR configuration except the configuration is under a different AF mode. For example:

R2(config)#router bgp 123
R2(config-router)#address-family vpnv4 
R2(config-router-af)#neighbor 1.1.1.1 route-reflector-client

We use dedicated RRs at work for some large setups and the routers are not always in the optimal data path between the network edges which is why pretty much all BGP books will tell you not to use the next-hop-self command on RRs because you could force traffic to take a suboptimal path.

And yes you should definitely read that book up to and including chapter 7, with probably the exception of chapter 5 unless you are particularly interested in cell-mode MPLS

tomtom1

router bgp 65535
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor edge peer-group
 neighbor edge remote-as 65535
 neighbor edge description iBGP
 neighbor edge update-source Loopback0
 neighbor x.x.x.x peer-group edge
 !
 address-family ipv4 vrf 1900
  redistribute connected
  redistribute static
  default-information originate
 exit-address-family
 !

What if you have the config above? What do the redistribute connected & static mean with regards to the VRF 1900 address family? And how will they effect the BGP routing process? Are connected & static routes being redistributed into VRF 1900 and then advertised via BGP in AS 65535? I think that would make no sense because a VRF normally has connected routes (interfaces with the vrf forwarding command configured)

Apologies if I may ask dumb questions that are (perhaps) explained in the MPLS / MP-BGP book, but still, I'm eager to learn.

fredrikjj

What do the redistribute connected & static mean with regards to the VRF 1900 address family?

BGP looks at the routing table for VRF 1900 (you can look at yourself with #show ip route vrf 1900) and redistributes connected and static routes found there into BGP as VPNv4 prefixes. A VPNv4 prefix is the VRF's RD added to the IPv4 prefix. These prefixes are sent to BGP neighbors that have negotiated that address family ('activated' under the vpnv4 address family). If the route targets associated with the VPNv4 prefix are found as 'import' route targets in a VRF at the BGP neighbor you are sending them to, that BGP speaker accepts the VPNv4 prefix*. It then installs the prefixes as IPv4 routes in the appropriate VRFs. The VPN label sent alongside the VPNv4 prefix is also installed in the FIB of the VRF in order to impose the correct label on incoming packets. The BGP next hop is then used to fetch another label from the global FIB. These two labels are used to forward the packet to the PE that originated the prefix into BGP and to the correct outgoing interface on that router. Because label forwarding is used, intermediary routers do not need to have customer prefixes in their IP FIBs.

*yes, this check can be disabled, but assume that it's not.

powmia

lrb wrote: »

1) RTs control which routes get imported into a VRF RIB and exported out of a VRF RIB.

Might come across as nitpicking, but that statement could be misleading in a significant way.

While Route Targets do control which routes get imported into a VRF BGP table, they do NOT control which routes get exported. All active routes in VRF BGP table will be advertised to VPNv4 peers (given that there is no filtering towards those neighbors). Notice I didn't say RIB. A RIB may contain routes from multiple protocols (BGP, IGP, static, connected). Redistribution controls which routes go from the VRF RIB to the VRF BGP table, visa versa.

The "route-target export" command simply assigns an extended community of type route-target to the routes being advertised out of that table. You can assign zero or many route targets, either way the routes are all still being sent out.

Extended communities are similar to standard communities, in the sense that they function as a "route tag." Extended just means that they are appended with a type value that identifies the overall purpose of that tag. Examples of extended community types would be bandwidth, route target, or site of origin.

When you want another site to join a specific L3VPN (when you want a VRF to import routes from another vrf, be it two different VRFs on one router, or VRFs on different PE routers identifying one customer site), you are using the "route-target import" command to identify routes with a specific tag (the route target extended community) that was used in another VRF's export statement. This is how you control NLRI distribution in an L3VPN environment.

lrb

powmia wrote: »

Might come across as nitpicking, but that statement could be misleading in a significant way.

I like nitpicking Thanks for the pickup because its a good point.

tomtom1

powmia wrote: »

When you want another site to join a specific L3VPN (when you want a VRF to import routes from another vrf, be it two different VRFs on one router, or VRFs on different PE routers identifying one customer site), you are using the "route-target import" command to identify routes with a specific tag (the route target extended community) that was used in another VRF's export statement. This is how you control NLRI distribution in an L3VPN environment.

Ok, think I got it. It's a step beyond my CCNP level stuff but there is a certain challenge to it. What if I have 2 vrf's on the same router, respectively 1 and 2. How can I configure it as such that routes from VRF1 are imported in VRF2? Would I put a RT export on VRF1 and a RT import on VRF2, matching VRF1's import? Is that the only thing required?

Edit: Configuring only the RT import / export is nonsense because RT's are BGP based. So there must be something more to it

powmia

Looks like you're getting it

tomtom1

A bit, but still not quite there. How can I share routes between VRF's on the same router? Do I need some kind of IGP that I can run inside the VRF?

powmia

If you are running MP-BGP. When you set a route-target from one VRF, then import routes with that route-target on another VRF... prefix information will go:

VRF_A RIB -> VRF_A BGP table -> global BGP table (As VPNv4 NLRI) -> VRF_B BGP table -> VRF_B RIB

Whether or not you advertise that information to CE routers, depends on the peering you have with them, either BGP or an IGP. This whole process, is no different whether you are doing it on the same router, or across an MPLS backbone.

I was saying that you are getting it... because of your edit, that yes... RTs are a BGP attribute.

tomtom1

It's clearly visible that you're a CCIE. The level of detail is amazing. However, your last post both answers and creates a new question. With the RT export set, the route goes into the BGP table as a VPNv4 prefix, if I understand correctly. How can it go into the global table from there, and what does that do with the routing? Does that mean the route also goes into the global RIB?

networker050184

It doesn't go into the global IPv4 unicast table, just the VPNv4 table (show ip bgp vpnv4 all). Routes from this table with a RT matching an import RT are imported into a VRF routing table.

powmia

Thanks networker, clear explanation. Poor semantics to use the word global... the globally present VPNv4 table