[c-nsp] MPLS VPN over mGRE

[Adam Vitkovsky]

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:jneiberger at gmail.com] 
Sent: Wednesday, January 30, 2013 6:16 PM
To: David Prall
Cc: Adam Vitkovsky; cisco-nsp at 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 <dcp at 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/xe-3s/ir
<http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/i
r-mpls-vpnomgre-xe.html> 
-mpls-vpnomgre-xe.html

David

--
http://dcp.dcptech.com



> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of John Neiberger
> Sent: Wednesday, January 30, 2013 10:55 AM
> To: Adam Vitkovsky
> Cc: cisco-nsp at 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.vitkovsky at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/