Excellent Joe, Right not even ldp is needed as the topmost/transport label is replaced by the gre encap. I still have some loose ends though
Ok so once the loopback reachability is in place (e.g. via ebgp with SP). iBGP sessions can be formed - btw does this work with two c-PEs acting like RRs -or there has to be an ibgp full-mesh??? In addition to safi128 also safi64 is negotiated between the ibgp speakers allowing them to exchange the profile info. Now Do routers sharing the same profile id participate in mGRE? -i.e. is the full mesh of tunnels created upfront??? Or When c-PE receives a vpnv4/v6 prefix -since the prefix info passes through the inbound route-map -the NH info of the prefix is bound to be reachable over the tunnel interface Does the c-PE than build the tunnel to the prefix NH??? I guess the tunnel source and BGP update source has to be the same ip address Though if not -maybe the mGRE overlay could be built across ipv6 environment right? adam -----Original Message----- From: Joe Cozzupoli [mailto:cozz...@gmail.com] Sent: Thursday, January 31, 2013 9:47 AM To: John Neiberger Cc: Adam Vitkovsky; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS VPN over mGRE Guys, check out the following session on Cisco Live 365: BRKRST-2045 (San Diego 2012 and/or London 2013) Sent from my iPad On 31/01/2013, at 19:06, John Neiberger <jneiber...@gmail.com> wrote: > I bet you're right. I should keep digging for some Cisco Live > presentation or something. I was hoping someone from Cisco would > respond and explain the magic fairy dust in this configuration. As you > said, it must be that the inbound route-map also causes the neighbors > to use SAFI 64 in outbound updates. The docs I've seen so far don't > say how it happens, they just said, "And in this step, magic happens" > or something similar. :) > > John > > > On Thu, Jan 31, 2013 at 1:02 AM, Adam Vitkovsky <adam.vitkov...@swan.sk>wrote: > >> Aah I see, so it’s got to be the route-map than, mapping the >> particular neighbor with a profile –causing the neighbors to >> negotiate safi 64 support. **** >> >> You could try issuing “sh ip b vpnv4 a nei x.x.x.x” to see whether >> safi >> 64 has indeed been negotiated between the peers. **** >> >> ** ** >> >> I bet the insides are explained in some cisco presentation. **** >> >> ** ** >> >> adam**** >> >> ** ** >> >> *From:* John Neiberger [mailto:jneiber...@gmail.com] >> *Sent:* Wednesday, January 30, 2013 6:16 PM >> *To:* David Prall >> *Cc:* Adam Vitkovsky; cisco-nsp@puck.nether.net >> >> *Subject:* Re: [c-nsp] MPLS VPN over mGRE**** >> >> ** ** >> >> That's exactly right. The part I can't figure out is what triggers >> the proper signalling. The BGP config for outbound vpnv4 updates >> looks like standard L3VPN. I'm trying to understand what causes it to >> send the tunnel information in the NLRI. I believe it is using SAFI >> 64. What causes it to use SAFI 64 instead of 128, which is what would >> normally be used for MPLS >> VPNs?**** >> >> ** ** >> >> That's the part that's baking my noodle. I'm just not sure how it's >> working under the hood.**** >> >> ** ** >> >> John**** >> >> ** ** >> >> On Wed, Jan 30, 2013 at 9:15 AM, David Prall <d...@dcptech.com> >> wrote:**** >> >> Sounds like you are using BGP Signaled MPLS VPN over mGRE which uses >> a Route-Map on the neighbor relationship to provide the tunnel information. >> >> http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/x >> e-3s/ir >> -mpls-vpnomgre-xe.html<http://www.cisco.com/en/US/docs/ios-xml/ios/in >> terface/configuration/xe-3s/ir-mpls-vpnomgre-xe.html> >> >> David >> >> -- >> http://dcp.dcptech.com**** >> >> >> >>> -----Original Message----- >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- >>> boun...@puck.nether.net] On Behalf Of John Neiberger >>> Sent: Wednesday, January 30, 2013 10:55 AM >>> To: Adam Vitkovsky >>> Cc: cisco-nsp@puck.nether.net >>> Subject: Re: [c-nsp] MPLS VPN over mGRE >>> **** >> >>> The type of MPLS VPN over mGRE that we're using doesn't use a >>> preconfigured tunnel interface or NHRP. As I understand it, the >>> peers share tunnel-related information in vpnv4 updates using a SAFI >>> of 64. This >> tells >>> the other peers that those prefixes are related to the mgre tunnel >>> and >> that >>> signals the receiving router to set up an adjacency over the >>> multipoint tunnel, but I'm not quite sure how it does this. I don't >>> understand what element of the config tells the router to use SAFI >>> 64 in the vpnv4 >> updates >>> instead of just treating them like regular L3VPN vpnv4 updates. It's >>> kind of confusing. There seems to be a lot of magic happening under >>> the hood here that I'm missing. >>> >>> John >>> >>> >>> On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky >>> <adam.vitkov...@swan.sk>wrote: >>> >>>> Wow they really shrunk it down to three commands plus the >>>> route-map, >>> now >>>> that's something. >>>> >>>>> or is there some other mechanism that triggers tunnel endpoint >>> discovery? >>>> I believe since it's called mGRE it has to be NHRP taking care of >>>> everything in the background. >>>> Does the loopback IP has to be allocated from a common range that >>>> has >> to >>> be >>>> shared among the PEs? >>>> >>>> I thought it's done via standard mGRE tunnels: >>>> >>>> interface Tunnel0 >>>> ip address 192.168.1.1 255.255.255.0 ip mtu 1440 ip nhrp >>>> authentication cisco123 ip nhrp map multicast dynamic ip nhrp >>>> network-id 1 tunnel source FastEthernet0/0 tunnel mode gre >>>> multipoint tunnel key 0 ip router isis 1 >>>> >>>> -maybe "mpls ip" cmd. wouldn't work with mGRE Tunnel Int. >>>> >>>> >>>> adam >>>> >>>> **** >> >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/**** >> >> ** ** > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/