I was reading through the configuration guide for MPLS VPN over mGRE to try to reverse engineer a configuration we have at work. This kind of hurts my head, but I think I've almost got it. The method we use is basically the same as this:
http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_mplsvpnomgre.html The config basically consists of: * VRF with RD and import/export RTs * l3vpn encapsulation method using GRE as the protocol * VPNv4 peer relationships between all endpoints needing access to this VPN * An ingress route policy on the VPNv4 peers that set the ip next-hop encapsulation to the l3vpn encapsulation method configured earlier That seems to be about it. The thing I don't yet understand is what starts the endpoint discovery process. I read somewhere that VPNv4 prefixes related to tunnels use a SAFI of 64, so when a peer receives those prefixes it would know that the sender wants to participate in the multipoint GRE VPN. If that's the case, what is it about the configuration that would cause the router to use that SAFI in the VPNv4 updates? I see nothing in the VRF or BGP config that specifically would cause it to behave any different. Why wouldn't it send regular VPNv4 routes? Other than the ingress route policy that associates incoming routes to the mGRE, I don't see what would cause the router to set the SAFI to 64 on advertised routes. Is that even how this works, or is there some other mechanism that triggers tunnel endpoint discovery? Thanks! John _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
