I found this lab really neat. They had me go back to RIP as the PE-CE routing protocol, which was nice to help me commit the syntax to memory. The trick this time was I had to create 4 different vrf's and allow the R5 vrf to act as a central services VPN. This acts kind of like a promiscuous port in switching terminology: all the other vrfs can access it, but individual vrfs are isolated from each other.
The interesting part here is I finally got to play around with import/export route targets. It actually worked pretty intuitively. Under the R5 vrf, I configured it to import and export all of the other route-targets. Once RIP propagated about 30 seconds later, everything magically worked. That was all there was to it. Way too easy.
The solutions guide specified to import R5 into the other 3 vrfs, instead of exporting to the other vrfs from R5. It appears to be 6 one way and a half dozen the other, but I do wonder if there is a standard to try to import when possible. Sort of like in an access-list it's a good idea to set it up inbound. This makes sense on an access-list because filtering it ingress saves processor time and bandwidth utilization.
Saturday, November 15, 2008
MPLS VPNs with eBGP Complete
Two interesting pieces to this lab.
First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.
To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.
The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.
Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 150.1.4.4 0 100 0 100 i
*> 10.1.7.0/24 10.1.37.7 0 0 100 i
*> 10.1.37.0/24 0.0.0.0 0 32768 ?
*>i10.1.45.0/24 150.1.4.4 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 150.1.4.4 0 100 0 200 i
*> 10.1.8.0/24 10.1.38.8 0 0 200 i
*>i10.1.46.0/24 150.1.4.4 0 100 0 ?
Note there is not a route to 10.1.38.0/24 in BGP. But who cares? And then it dawned on me.
When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.
This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.
To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.
Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.
*>i10.1.38.0/24 150.1.3.3 0 100 0 i
*> 10.1.46.0/24 0.0.0.0 0 32768 ?
First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.
To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.
The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.
Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 150.1.4.4 0 100 0 100 i
*> 10.1.7.0/24 10.1.37.7 0 0 100 i
*> 10.1.37.0/24 0.0.0.0 0 32768 ?
*>i10.1.45.0/24 150.1.4.4 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 150.1.4.4 0 100 0 200 i
*> 10.1.8.0/24 10.1.38.8 0 0 200 i
*>i10.1.46.0/24 150.1.4.4 0 100 0 ?
Note there is not a route to 10.1.38.0/24 in BGP. But who cares? And then it dawned on me.
When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.
This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.
To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.
Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.
*>i10.1.38.0/24 150.1.3.3 0 100 0 i
*> 10.1.46.0/24 0.0.0.0 0 32768 ?
MPLS VPNs with EIGRP Complete
Nothing too challenging with this lab. EIGRP is configured similarly to RIP where address families are named under the EIGRP process. What is interesting is that different autonomous system numbers are used for each EIGRP vrf.
Friday, November 14, 2008
MPLS VPNs with OSPF Complete
I'm getting faster and faster at these. OSPF was pretty straightforward, there was probably just one oddity I found.
When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.
However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.
When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.
However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.
MPLS VPNs with RIPv2 Complete
Wow, I actually am getting better at this MPLS stuff. When moving from static routes to RIP, the complexity increases greatly. It's a good thing RIP itself is such a simple protocol.
So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.
For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under 10.0.0.0, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.
I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.
I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.
So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.
For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under 10.0.0.0, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.
I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.
I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.
Thursday, November 13, 2008
MPLS VPNs with Static Routing Complete
Points to remember when configuring MPLS VPNs:
First create the vrf and associate the rd and import/export rules
Next assign the interfaces to the vrf and reapply IP addresses
Then configure the BGP vpnv4 address family, activating the other PE router and send both communities
Also under BGP, configure the ipv4 vrf address family, redistributing as appropriate
Finally, configure any necessary ip route vrf's.
Use show ip route vrf *, show ip bgp vpnv4 all, and ping vrf to verify connectivity
I really need to commit to memory when to use the vpnv4 address family and when to use the ipv4 vrf address family. It makes sense conceptually. The vpnv4 family includes the extended communities, and basically acts as a type of tunnel between PE routers. Then, each ipv4 vrf is like a pvc inside of that tunnel. Finally, the vrf itself describes what routes get leaked between each individual vrf.
The router uses rd's to keep track of vrf's. We use the vrf name to associate the vrf with interfaces and bgp.
The router uses rt's to advertise vrf's across vpnv4 through the use of extended communities.
First create the vrf and associate the rd and import/export rules
Next assign the interfaces to the vrf and reapply IP addresses
Then configure the BGP vpnv4 address family, activating the other PE router and send both communities
Also under BGP, configure the ipv4 vrf address family, redistributing as appropriate
Finally, configure any necessary ip route vrf's.
Use show ip route vrf *, show ip bgp vpnv4 all, and ping vrf to verify connectivity
I really need to commit to memory when to use the vpnv4 address family and when to use the ipv4 vrf address family. It makes sense conceptually. The vpnv4 family includes the extended communities, and basically acts as a type of tunnel between PE routers. Then, each ipv4 vrf is like a pvc inside of that tunnel. Finally, the vrf itself describes what routes get leaked between each individual vrf.
The router uses rd's to keep track of vrf's. We use the vrf name to associate the vrf with interfaces and bgp.
The router uses rt's to advertise vrf's across vpnv4 through the use of extended communities.
SP Volume I Basic MPLS Complete
The biggest challenge here was in getting Dynamips up and running and configured. Fortunately, IE has a great guide which saved me a lot of work. I first tried to run it in Windows, but the performance was too poor. So I switched to Linux, and I can get the Vol I equipment up and running just fine.
The Basic MPLS lab was just what it says. Just needed to throw OSPF and BGP on a few routers and then put MPLS on the core. It was a nice exercise just to watch the pings propagate even though the core routers don't have a route to the final destination.
I had two mistakes in my configuration that I was able to correct pretty quicly. First, I missed mpls ip on one of the interfaces. Because it was missing, some of my hops were untagged in the mpls forwarding table. Simply checking the mpls neighbors at each router pointed me to the issue pretty quickly.
The second mistake was that I didn't put next-hop-self on the PE routers. This is necessary because the core needs a route to the next BGP hop, just not to the final destination. By deafult, iBGP does not update the next-hop and leaves it as the first eBGP hop.
The Basic MPLS lab was just what it says. Just needed to throw OSPF and BGP on a few routers and then put MPLS on the core. It was a nice exercise just to watch the pings propagate even though the core routers don't have a route to the final destination.
I had two mistakes in my configuration that I was able to correct pretty quicly. First, I missed mpls ip on one of the interfaces. Because it was missing, some of my hops were untagged in the mpls forwarding table. Simply checking the mpls neighbors at each router pointed me to the issue pretty quickly.
The second mistake was that I didn't put next-hop-self on the PE routers. This is necessary because the core needs a route to the next BGP hop, just not to the final destination. By deafult, iBGP does not update the next-hop and leaves it as the first eBGP hop.
Subscribe to:
Posts (Atom)
Posts
