Hi Praveen,
Sorry about the delay. I am just back from our EMEA company event and have been
a lot busier than I planned.
> [PRAVEEN] For one-liner question, we could only imagine the scenario that
> you are trying to solve. And this is what we could come up. May be you can
> provide more detailed question on what scenario you would like to solve.
> We could help in answering those scenarios.
>
> When admin changes the prefix of a spoke, spoke¹s existing static tunnel
> with Hub, gets re-negotatiaged for updated prefix in Tsi/TSr payload. This
> event updates the Hub about changed prefix information. Is that what you
> wanted to know?
Yes, this is the information I was looking for. So in a nutshell, when a prefix
in spoke network is changed, it takes an additional change in the central DB
and a tear down of the tunnels.
This is not very attractive compared to a routing protocol which can do it
instantly and without affecting the other prefixes. Especially in the presence
of a large number of prefixes behind spoke(s).
Also, I am taking it that there is one such file per spoke ? Or is it one big
file containing all the spoke prefixes ?
>>
>> Before going any further, is this resource exclusively exchanged between
>> hub & spoke or also between spokes ?
>
>
> [PRAVEEN] ³resource² you means ADVPN_INFO payload or Subnet information?
> ADVPN_INFO exchanged between spokes. Subnet information exchanged part of
> Tsi and TSr during IKE negotiation (which means between hub & spoke and
> between spokes as well).
I mean the ADVPN_INFO pointing to the URL with the list of prefixes.
The question is now: who has access to those resources ? Who can update the
file(s) on the fileserver(s) ? This raises the whole question about role based
management.
It also means the change management is now quite complex since in order to
update spoke prefixes you also have to change the central prefix files.
One of the requirements which was "no change on the central devices when adding
a branch" is in contradiction with this method. OTOH, I am pondering that the
spokes could automatically update the central file(s) in which case it would
not be very different from a routing protocol...
thanks,
fred
>>
>> thanks,
>>
>> fred
>> _______________________________________________
>> IPsec mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
