I'll have to sanitize them. Even though this is a testbed, its mimicking the configs of a gov't production system.
No, I don't have a router ID specified for each VRF. I didn't think I'd need to since there isn't really any routing happening on each VRF? I thought it was basically one main BGP routing table for all the MPLS collectively. Should I be doing that and what would I use for the router ID for each VRF, would they all be the same?
... View more
I have a lab set up to test a new network design where we want to be able to keep virtual networks separate across WAN links. So, I've set up a MGRE tunnel encrypted with IPSEC for securing the traffic, there is only one remote site at this time. Over these MGRE tunnels I'm running MPLS, which is also running in our core. So we're essentially trying to extend the VRF's in our core out to the remote sites.
Between the Hub router and the remote I'm running eBGP and everything seems to be working correctly. I have multiple VRF's on either side and loopbacks configured up in the VRF's and I can ping remote loopbacks if I originate the ping in the correct VRF and such.
The problem is that I'm trying to connect the hub to a Nexus 7K via iBGP, which has the same VRF's and get everything working from it. This is where it fails. I can see the routes in the BGP table, but they're flagged as invalid and won't install into the routing tables on the Nexus.
I'm trying to figure out why this is and remedy it, but its not working. The topology is quite simple. Nexus is connected to Hub router (ISR4451 via iBGP) and Hub is connected to Remote (ISR4451 via eBGP).
192.168.10.100 is the loopback on the Hub router, which I can ping from the Nexus. 192.168.20./24 is a network simulated by a loopback on the Remote router.
sh ip bgp vrf vrf-1 192.168.20./24 BGP routing table information for VRF vrf-1, address family IPv4 Unicast BGP routing table entry for 192.168.20./24, version 171 Paths: (1 available, best #0) Flags: (0x080002) on xmit-list, is not in urib, is not in HW, vpn: version 534, (0x100002) on xmit-list Multipath: iBGP
Path type: internal, path is invalid(rnh unreachable), imported same remote RD, no labeled nexthop AS-Path: 65100 , path sourced external to AS 192.168.10.100 (metric 0) from 192.168.10.100 (192.168.10.100) Origin IGP, MED 0, localpref 100, weight 0 Received label 62 Extcommunity: RT:65000:1
VRF advertise information:
VPN AF advertise information:
Cisco seems stumped, any ideas or suggestions what to look for?
... View more
Found this discussion while trying to attempt something similar myself.
What I ended up doing, that might be a better solution, was to go into "Security" and "AP Policies" and change it from "Accept Manufactured Installed Ceritificate" to "Authorize LSC APs against auth-list". How exactly you do it depends on how you authenticate your AP's to your controller though. In my case I used MIC's and not LSC AP's, and >definitely< didn't define an auth list. So by changing it, I effectively told it not to allow any AP's to connect at all.
Worked fine for me, after I got done doing what I needed to do, I changed it back and they were able to authenticate again.
... View more