This is the lab that was built in Keith Barker's MPLS Fundamentals CBT nuggets course - so credit where it's due.ĮIGRP configured in a VRF uses a similar 'address-family' command to BGP. I suspect it's because when you connect to the console you actually go straight to the system context rather than the admin context, so the AAA configuration in the admin context is ignored.
#MPLS FUNDAMENTALS CBT NUGGETS KICKASS SERIAL#
I did some testing and troubleshooting, basically it boils down to For elevation while using the serial cable, you need to set the enable password at the system context level. Via console however, the password just wouldn't work at the enable prompt. Via SSH to the ASA - After the initial username/password login, you then have to run the enable command and type the password again. The units were set up to use a radius server, on routers you're placed straight into privileged exec upon login but that's not the case with an ASA. Preparing to bring the replacement unit back into the HA pair, I discovered that I couldn't actually get into the privileged exec mode via the console cable. We had an ASA fail with the clock signal component issue that's plagued several Cisco device families, fortunately it was a unit that was in a HA pair so we didn't suffer downtime. So the solution for me was rather frustrating and mundane - change the RD of the VRFs I needed to extend to a 2 byte ASN - but at least it's working! I also investigated the concept of RD rewrite It's not available on regular iOS, only iOS XE or XR. I investigated some of the AS notation options but they weren't relevant - I simply couldn't specify (or recognize) a 4 byte ASN as an RD. My best guess is that this is either an oversight or a bug in the latest iOS that the 7206 can run (15.2(4)M11).
#MPLS FUNDAMENTALS CBT NUGGETS KICKASS UPDATE#
So what would the neighboring router do? It would consider this second update to be a replacement of the previous update - the same network but different attributes! So it would remove the network 10.0.0.0/8 from the VRF V1 and add it to VRF V2! So, the short version: The NetIrons were sending the routes with an RD where the first number was 4 byte ASN, which the 7206 was completely ignoring. Now, a second update comes in (or a second entry from the single update is processed), and guess what - it says that there is the same network 10.0.0.0/8, just with the RT set to 1:2. What would the neighboring router do? It would place the route into the corresponding VRF V1. Now imagine how the BGP updates would look on the wire: first, an update comes, saying that there is a network 10.0.0.0/8 with the RT set to 1:1. It turns out that the RD isn't only locally significant, it's actually prefixed on the mBGP route advertisement so the receiving router can differentiate if it receives the same prefix from two different VRFs. After after a little more testing I noticed that the RD displayed under that command was actually the sending router's RD. show ip bgp vpnv4 all on the 7206 showed me the mBGP routes I had learned, with their appropriate RT and the 10:10 RD that I thought referred to the VRF they were landing in. I set up a test VRF with RD and RT of 10:10 and everything worked immediately. I was seeing some strange asymmetric behavior, where the newer routers in the existing MPLS network (Brocade NetIrons) were receiving the routes exported from the 7206, but the 7206 was not receiving their routes. No bother, that's what RT import and export are for - right? Wrong. The older router (VXR 7206) did indeed support 4 byte ASNs for most things, but wouldn't let me set a VRF's RD with one. The standard that had been used for the RD and RT in the existing MPLS network was ASN:VLAN, and the BGP ASN happened to be 4 byte. One of the more interesting challenges I encountered during this project was how mBGP distributes routes. I've been working on bringing an older router functioning as an LNS into an MPLS network, so we can land dial in connections within a VRF.
0 kommentar(er)
