Re: [c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue

2018-01-29 Thread Justin M. Streiner

On Mon, 29 Jan 2018, Aaron Gould wrote:


I'm just trying to learn about OTV as I haven't heard much about it...  is
OTV an IETF standard ?


OTV is a Cisco proprietary protocol with some important design 
considerations if you want to go in this direction.  This includes 
things such as allocating a VDC for the OTV magic, and allocating a 
port group (an ASIC) on one or more of your linecards to dedicate to that 
VDC.  I think there are also some limitations on the types of linecards 
you use for the OTV interconnection between VDCs.


jms
___
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/


Re: [c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue

2018-01-29 Thread Gert Doering
Hi,

On Mon, Jan 29, 2018 at 01:07:50PM -0600, Aaron Gould wrote:
> Also, I wonder why I would use one of these (EVPN, VX-LAN, OTV) over the
> other ?  let me know if those 3 don't belong in the same comparison family.

Because you bought Cisco gear from one of their business unit, and not
from a different one.

In the end, all three protocols can be used to do similar things (bridging
layer 2 networks across an IP or MPLS network), but for reasons unknown to
man, it's fully impossible for Cisco decision makers to agree internally
which one to implement.

So the Nexus BU gives you OTV, the ASR9000 BU gives you EVPN and VXLAN,
the Cat6500 IOS BU gives you nothing at all ("VSS and VPLS", or something
like that).

Sounds annoyed?  No idea why.

gert
-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
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/

Re: [c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue

2018-01-29 Thread Aaron Gould
I'm just trying to learn about OTV as I haven't heard much about it...  is
OTV an IETF standard ?

Also, I wonder why I would use one of these (EVPN, VX-LAN, OTV) over the
other ?  let me know if those 3 don't belong in the same comparison family.


I just watched a cisco video and see that the OVT AED (authoritative edge
device is only one, so I guess multi-active-active forwarders which EVPN
brags about can't be done in OTV ?)

Also, I see OTV is gre encaped, and I hear that vxlan is udp encaped, and
evpn, I forget, but I think is just eompls, so I guess vxlan or otv can be
done over non-mpls clouds ?...maybe these are things that would push
me/others in one direction or the other when choosing a l2-emulation
mechanism for DC or whatever we need it for.

- Aaron


___
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/


Re: [c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue

2018-01-29 Thread Richard Clayton
Hi Guys

I think I have the reason for the behavior in my lab.  I have the 'silent
host' issue which happens in labs but generally doesn't happen in live
networks.  For my host devices I used Cisco routers with an IP address on a
single interface, all these devices were doing is a ping and and ARP to a
single IP address.  In a production network these hosts would be
workstations and servers and would be a lot more chatty, generating
broadcast traffic.  When I drop the CSR1 site 1 WAN overlay the remote
Cisco host does not generate any new broadcast traffic, new broadcast
traffic would flood from the CSR1 site 2 across the overlay and eventually
into the 'customer' layer 2 at site 1.

So in summary, in a production network the hosts would generate enough
broadcast traffic to keep failover connectivity issues to a minimum.  In a
lab with silent hosts, you will have to wait 5 minutes for the 'customer'
layer 2 mac address table to age out before connectivity is restored.  For
info I used Cisco routers as end hosts because they were easy, quick and
lightweight to spin up.

I still don't fully understand why the OTV host doesn't generate a TCN as
documented so if anyone could get an answer on that it would be great.

For now I am happy to design OTV into my customer solution.

Thanks

Rick

On 26 January 2018 at 15:23, Richard Clayton  wrote:

> Hi Guys
>
> I have configured Multihomed OTV in a virtual lab on EVE-NG using Cisco
> CSR's.  The lab is 2 x CSR at one site both connected to layer2 switch and
> a single CSR at a remote site.
> Everything works good apart from one thing.  At the dual router site, when
> I drop the OTV WAN/Overlay interface on the active CSR R1, the remote mac
> appears in the R2 bridge-domain (as it should) but the 'customer' layer 2
> switch mac address table still show the mac address as facing the R1 LAN.
> After 5 minutes the mac table times out and traffic is then restored over
> the R2 path.
> Is there any way R2 can update the customer L2 switch when the remote mac
> moves over to it to make the failover quicker?
> I did read a Cisco article that said if spanning tree is enabled on the
> OTV router, it will send out a TCN which will update the L2, I have
> spanning tree enabled on the OTV routers but when I drop the OTV
> WAN/Overlay interface, it does not send out a TCN, I had wireshark running.
>
> Thanks
> Rick
>
>
> --
> If you try to reinvent the wheel you will end up with something non-round
> and should expect an uncomfortable ride. The wheel has no copyright.
> Richard Clayton - 17/11/2014.
>



-- 
If you try to reinvent the wheel you will end up with something non-round
and should expect an uncomfortable ride. The wheel has no copyright.
Richard Clayton - 17/11/2014.
___
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/