this is good news I agree that the change is needed only on the border routers as the RR just do their job of reflecting VPNv4 prefixes between clients, and they don't care about VRFs they do not need to have vrf BORDER defined on them at all.
With the command moved to vrf context it provides granular control. Nice to know.
Hope to help
... View more
I see what you mean. We would apply this ACL to the outbound BGP config for the other ISPs that we peer with (not AS300). I only included one internet provider in my example, which was a mistake on my part. So, a better example would be to apply the same list to a different provider with AS400. The "permit any" lines in the list are essentially to get around the explicit deny. I believe the thought was that we need the ^100_[0-9]$ to advertise routes with our own AS in the path for iBGP purposes, but now that I think of it, we really don't need this. We also have a "deny private space" prefix list applied to prevent private space coming in from our upstream providers so that we only get a public internet routing table from each of them. I left this detail out in my original post as well.
As far as customer control, this list is for the upstream neighbors we peer with. We have have a prefix-list/as-path ACL tied to a route-map on our access equipment (ASR920/NCS540) to filter inbound routes from our customers to prevent them from advertising the universe to us. Generally, customers only want a default route, so this can be done on our access gear. Customers wanting a full table we have to use a L2VPN of VPLS to get them to a border device to facilitate this. We also use a prefix-list with our as-path ACL from above to make sure that we only advertise what we want. This way, even if a customer advertises the universe to us AND our inbound filter is wrong, the route won't be propagated to our upstream peers.
Also, I am learning a great deal already from the post you provided earlier. Thank you very much for the info. I don't know how I missed it in my initial search!
... View more
There is not enough "market" for Cisco to R&D a stratum 1 module.
It is better to get a GPS-based stratum 1 appliance elsewhere. Otherwise, one can use a pair of Linux servers to act as a stratum 2 appliance. Better yet, Linux boxes can be hosted on a Raspberry Pi or Beagle Bone units. Either one can be powered up using the USB ports. We have a few in our DC and they're being powered using the USB ports of the HP servers. Works very well!
Read this: Raspberry Pi as a Stratum 1 NTP server & Quick start NTP on the Raspberry Pi
The beauty of the Raspberry Pi setup are:
1. Components are inexpensive (main component cost <US$100 plus extra for the NTP board); and
2. Open source
... View more