[c-nsp] MPLS VPN over mGRE
Adam Vitkovsky
adam.vitkovsky at swan.sk
Thu Jan 31 05:43:19 EST 2013
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:cozzupj at gmail.com]
Sent: Thursday, January 31, 2013 9:47 AM
To: John Neiberger
Cc: Adam Vitkovsky; cisco-nsp at 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 <jneiberger at 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.vitkovsky at 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: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/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-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/****
>>
>> ** **
> _______________________________________________
> 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/
More information about the cisco-nsp
mailing list