I was running through the MPLS section of the INE workbook. Nothing too major at first and then the fun started. I have to say, I kinda like MPLS. It has this funny way of looking all sweet and innocent and then biting you on the buttocks with all the underlying complexity. Anyways, on to my lessons learned and things I found fun or interesting.
So when running VRF Lite, you can do a static route from one VRF to another through the use of ip route vrf and stating the interface the traffic will flow out of. This can get cumbersome in some situations but in others, it is fine for a few small fine tunings. Think small deployments. Large deployments and static routes just suck.
When configuring MPLS LDP and you want to use the physical interface IP as the transport IP, use the command mpls ldp discovery transport address interface in config-if or subif mode. Or if nothing else you can just state the IP. Good for when not having the IGP send out the loopbacks or just to be different. :)
With MPLS, not only configure MPLS globally but it is good to also do it on each interface with mpls ip. If using OSPF and say you want it enabled on all the OSPF interfaces, use the command mpls ldp autoconfig under the OSPF process.
So I keep forgetting that when I set up MP-BGP, you have to source it from the loopback and it has to have a /32 subnet-mask. Crap. Also need to realize the routes are to be redistributed with either static or connected. Combine that with not sending communities and well I just jacked up that config horribly. I was right in my thinking, just not in the execution. I just need to get the steps correct now.
When using export maps, set the export route-targets based on the prefixes as wanted and then if there is a default target, don't forget to use a match any statement. Think of it as the catch all.
So, you want OSPF rouutes traveling across the MP-BGP to be recognized on the far side as external. No worries. Configure the PEs in different OSPF domains. This will force the routes to be external. Also if the routes are being blackholed., look at turning on capability vrf-lite which will cause the routes to not look at the down bit.
For an OSPF sham-link, the interface is usually a loopback for the source and destination and has to be known in the VRF. You can advertise this into BGP directly on the PE, since it is a good idea to advertise these into the VRF with a method other than OSPF. Good ole network statement in BGP address-family for the vrf.
Site of Origin is a filtering technique for when a network is multi-homed. When using it, you don't have to use EIGRP route tags and BGP communities to filter routes. You configure it with a route-map that sets the extcommunity soo value to ASN:XX. That route map is applied at the interface level via ip vrf sitemap <ROUTE_MAP>. Now as the route leaves a router, it is tagged and if the router sees it again or a route with the same SoO, it drops it. This is a lot like using route tags but with a lot less work. Don't apply it on the MPLS links. Apply it on the links to the customer site and the links for the backbone. That way all routes that enter and leave that interface are checked. Also a router doesn't ahve to be running VRF to use the sitemap command.
There are two ways to apply a sitemap. One is on the PE interface facing the CE routers using the same SoO on every PE router. Doing this does not allow the MPLS core to be used as a backup between sites. The second way is to apply different SoO values at every PE router. I like the idea of using the same SoO value at each site becaue then you make sure that the route doesn't get put back in at the same location but still allow the use of all links.
With BGP SoO, you configure it per neighbor on the PE router. It is used to prevent routing loops in a multi-homed scenario. Hmm... What does this sound like? Maybe EIGRP SoO. You can do it via route-maps and neighbor route-map commands but to me neighbor soo is much more elegant. You can use a different value on each PE to the CE and then the CEs can match their respective PEs to each other. Keeps the backdoor link a backdoor and allows full route table "respect". If you disrespect the route table, it will make loops that will drive you insane. And if you want to see how many prefixes are getting filtered via SoO, look in the neighbor information under BGP (show bgp vpnv4 unicast vrf <NAME> <NEIGHBOR>). It will list the SoO loop information.
So you have this MPLS cloud connecting multiple sites to each other. Great. Awesome. How about Internet? There are two ways to get the routes to the users for Internet access. You can set the connection to the Internet as a VRF and import and export the routes using route-targets for one. That works pretty easy. Path 2 is to have the Internet connected to the global route table and then create static routes for the VRFs. Easiest way is to the it with the default route for the VRF pointed to the global table and interface. You may then need to do NAT on the addresses as they go out if they are private. I like the VRF method. Just seesm easier and I am all about that.
Think that MPLS MP-BGP is fast? Want it to go faster? There are three factors for how the speed is affected.
1) Time for an IGP update to be redistributed into BGP. This is more event-driven now in newer code, so it is nearly instantaneous.
2) Time to send updates to peers. This can be done faster with setting the neighbor advertisement-interval to 0. This will send the updates not and not wait for a batch job. For newer code, this is the default. Still, I like to be explicit.
3) Time needed to import MP-BGP VPNv4 prefixes into the local table. You can use bgp scan-time under the VPNv4 address-family but that is deprecated. Instead, you can use import path selection all under the vrf address-family in BGP.
No comments:
Post a Comment