[c-nsp] Recovery time under interface failure - VPLS - MPLS L3 VPN- Plenty L3

[Oliver Boehmer (oboehmer)]

alaerte.vidali at nsn.com <mailto:alaerte.vidali at nsn.com> wrote on Monday,
June 30, 2008 2:55 PM:

> Hi Oliver,
> 
> Question is very specific to issue in ethernet connection between R1
> and laptop and comparing recovery time under this failure in VPLS,
L3MPLS
> VPN and pure L3 routing.
> That is, how VPLS will influence the recovery of the MAC address on R1
> (delay introduced by VPLS).

Ah, so you mean how long it takes when the ethernet comes back up and
the client can resume connecting to the server? Well, assuming there is
no STP delay (portfast/etc.) this should be rather quick (similar to a
switched environment, with a bit higher propagation delay if the VPLS
spans a large geography). It's the same flooding/learning method.

When it comes to routing (L3VPN or "regular"), I guess it depends on
wether the route to the destination is already known or not. If not,
getting routing information over to the other side can take ~5-8 seconds
for regular (untuned) IGP or even more for L3VPN (depends on BGP MRAI
timers and RD-setup/import-delay).

	oli



> 
> -----Original Message-----
> From: ext Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> Sent: Sunday, June 29, 2008 4:48 AM
> To: Vidali Alaerte (NSN - BR/Rio de Janeiro);
> cisco-nsp at puck.nether.net 
> Subject: RE: [c-nsp] Recovery time under interface failure - VPLS -
> MPLS 
> L3 VPN- Plenty L3
> 
> alaerte.vidali at nsn.com <> wrote on Saturday, June 28, 2008 5:21 PM:
> 
>>  Hi,
>> 
>> Considering following simple topology:
>> 
>> Laptop-----(e1)R1-----R2----R3----Server
>> 
>> ...and that OSPF timers are the same and BFD is not used (no failure
>> recovery optimization used) on all scenarios:
>> 
>> What would be the recovery time when interface etherne 1 (from
>> laptop to R1) fails in these cases: 
>> 
>> -Just IP routing between R1 and R3
>> -VPLS between R1 and R3
>> -MPLS VPN between R1 and R3
>> 
>> If I am not wrong, in VPLS case R1 will remove MAC address and
>> communicate that to R3, but not sure if it will impact final
>> connectivity recovery time between laptop--server.
>> (sorry, no lab to test right now)
> 
> Hmm, where should above topology recover to? There is no alternate
> path 
> between client and server here? In general, convergence times depend
> on 
> several variables.. sub-10-sec is a ballpark figure you can use, but
> it 
> can also take longer (when BGP is involved) or quicker..
> 
> 	oli