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

[adamv0025]

> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Monday, February 05, 2018 3:35 PM
> 
> Use the technology long enough for a specific application, and that use gets a
> new name (and acronym to boot). Once a new name/acronym has been
> established, vendors and other interested parties find a new way to re-
> describe the same technology as being applicable to a specific use-case, and
> re-build it in such a way to suit that particular application at a much more
> fundamental level - purpose-built software and hardware in tow.
> 
Yeah like RFC3107 used in Inter-AS Opt.C since ever and then all of a sudden 
"Seamless MPLS" came to save the world (well the "MPLS all the way down to each 
cell site" world anyways).  
  

> The talent is amongst operators knowing when a technology is just a fad, and
> not buying into it. For me, that was, and always has been, VPLS. Segment
> Routing is another one, but let me not start a war.
> 
Agreed, tell me one thing I can't do with RSVP signalled LSPs, well other than 
scale out related stuff -oh and I'm talking biblical per flow LSPs type of 
scale out. 

 
> The trick is not about knowing which technologies will actually help your
> operations and/or business, but rather, knowing which ones won't. It's a fun
> game :-)...
> 
Oh yeah a fun game it is indeed that's why most of us are in (I hope). 
But then there's also the HW side of things and my observations are that while 
there's a bunch of architects well versed in SW, only a handful of them invest 
time and effort to tell a good routing system architecture from a bad one. 
(Honestly who knows why correct settings for pre-classification, backpressure, 
VOQs, etc... are essential). 
I mean I can have CP doing all sorts of fantastic stuff but if the DP can't 
deliver datagrams in desired order or not at all if overloaded then the CP bit 
is useless. After all the end game is to transport data reliably and 
efficiently not to do fancy stuff in CP.
(The CP bit is there just to make it ever easier for Ops or AI to program the 
DP). 
How I see it we came a long way from manually defining exactly "what" using 
static routes, through defining just "how" using variety of dynamic protocols 
and then back to static routes/labels -now programmed by AI from a centralized 
controller, to close that circle soon. 

adam


netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
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

[Aaron Gould]

Thanks y’all, to be clear, are you saying “…VPLS. Segment Routing…”  you view 
those as fad technologies ?  …or the opposite?

 

Yeah, I remember working for the US Navy in San Diego in 1999 and sitting in a 
class taught be a vendor-provided SE, FORE Systems.  The class was about, yep 
you guessed it with the mention of the vendor (FORE)…class was on ATM… LANE…. 
Etc.  You may recall that in the late 90’s, early 2000’s, ATM was going to save 
the world.  At one point in the class, the instructor paused and made a 
seemingly prophetic statement… he said, all this ATM stuff is new and great and 
all that, but he then erased the board and said this will all be superseded by 
this technology in the next several years… and he wrote 4 letters on the 
board…. M-P-L-S…. then we all stared at him and didn’t know what he was talking 
about, because ATM was new and awesome and we were completely taken up in the 
latest 20 million dollar US Navy atm-to-the-desktop project…. And also , we had 
no idea what he was talking about with mpls…. Then he erased those 4 letters 
and went back to talking about LECS, LES, BUS, LEC operations in LANE ELAN’s….  
K   LOL….

 

-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

[Mark Tinka]

On 5/Feb/18 16:01, adamv0...@netconsultings.com wrote:


> When I started in networking I was setting up p2p leased lines between
> csu/dsu boxes (t-shooting fractional T1s and stuff on DSX cross-connects).
> Then we were migrating these to FR or ATM circuits. And then we were
> migrating FR/ATM to MPLS cause MPLS was any to any. And heck couple years
> later there are requests from customers to go back to these p2p circuits
> (using PW over MPLS) to close the circle. 
> So back in the days it could happen that the links between MPLS devices
> where set up over FR network(which in itself was built on top of these
> leased lines) and you'd have customers being migrated off of the very same
> FR network to MPLS just to ask for the same setup they have with FR i.e. hub
> and spoke p2p links and own IP routing, so what they got at the end was
> product based on VPWS.
> This was before the Carrier Ethernet became a thing -where we sell p2p
> Ethernet links for SPs to build their MPLS backbones on top and don't need
> to lease, well not T1s but fibre/lambdas. 
> So here we are, couple years and overlay headers later still doing the same
> thing. 

It all eventually comes back around, in some form or other, as you
highlight.

Vendors want to keep themselves busy, so there will always be a "hit"
technology that makes it "easier" to do the same thing we've always been
doing. The reason it becomes a thing is because operators get excited
because of new technology, but more importantly, "it" promises to be
cheaper to deploy and manage, which translates into "cheaper to buy",
and then it catches on.

Use the technology long enough for a specific application, and that use
gets a new name (and acronym to boot). Once a new name/acronym has been
established, vendors and other interested parties find a new way to
re-describe the same technology as being applicable to a specific
use-case, and re-build it in such a way to suit that particular
application at a much more fundamental level - purpose-built software
and hardware in tow.

And on and on, the ride spins.

This is not even accounting for the 5 largest content houses that are
driving the strategy for equipment manufacturers.

The talent is amongst operators knowing when a technology is just a fad,
and not buying into it. For me, that was, and always has been, VPLS.
Segment Routing is another one, but let me not start a war.

In 2013, at a meeting in Paris, it was touted that MPLS had reached its
end-of-life and was going to become obsolete to die in favor of skinnier
overlays such as VXLAN. One year later at the same meeting, MPLS was
still alive and well. It's 2018 now...

The trick is not about knowing which technologies will actually help
your operations and/or business, but rather, knowing which ones won't.
It's a fun game :-)...

Mark.
___
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

[adamv0025]

> From: Aaron Gould [mailto:aar...@gvtc.com]
> Sent: Thursday, February 01, 2018 5:05 PM
> 
> So I think (I could be wrong as I'm not a server guy) that all this L2
network
> emulation is because of server virtualization and moving vm's or vmotion
or
> something like that, and that they need to be in same ip subnet (aka bcast
> domain) correct ?
> 
> *if* that's true, and *if* all this layer 2 networking madness is because
of
> that point stated above, I would think that someone (vendors/standards
> bodies/companies) would/should be working really hard to make that server
> stuff work in different bcast domains (different subnets)...so we wouldn't
> have to do all that L2 stuff
> 
Well there are attempts but I think it might actually need the whole IPv6
shebang to take off till these become BAU.

Oh and I'd like to correct myself actually I listed VPWS as one of the
technologies created for DCI but that's not true as it was developed well
before DCI was a thing, to transport anything over MPLS hence the AToM. 
There's an interesting story about these L2 overlay circuits actually, seems
like they have been around since ever. 
(Anyone here that remembers SNA over DLSW and SDLC on serial interface to
mainframe?)
When I started in networking I was setting up p2p leased lines between
csu/dsu boxes (t-shooting fractional T1s and stuff on DSX cross-connects).
Then we were migrating these to FR or ATM circuits. And then we were
migrating FR/ATM to MPLS cause MPLS was any to any. And heck couple years
later there are requests from customers to go back to these p2p circuits
(using PW over MPLS) to close the circle. 
So back in the days it could happen that the links between MPLS devices
where set up over FR network(which in itself was built on top of these
leased lines) and you'd have customers being migrated off of the very same
FR network to MPLS just to ask for the same setup they have with FR i.e. hub
and spoke p2p links and own IP routing, so what they got at the end was
product based on VPWS.
This was before the Carrier Ethernet became a thing -where we sell p2p
Ethernet links for SPs to build their MPLS backbones on top and don't need
to lease, well not T1s but fibre/lambdas. 
So here we are, couple years and overlay headers later still doing the same
thing. 

adam


___
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

[Richard Clayton]

The reason this particular customer wants to extend layer 2 is Vmotion.

On 1 Feb 2018 17:04, "Aaron Gould"  wrote:

> So I think (I could be wrong as I'm not a server guy) that all this L2
> network emulation is because of server virtualization and moving vm's or
> vmotion or something like that, and that they need to be in same ip subnet
> (aka bcast domain) correct ?
>
> *if* that's true, and *if* all this layer 2 networking madness is because
> of
> that point stated above, I would think that someone (vendors/standards
> bodies/companies) would/should be working really hard to make that server
> stuff work in different bcast domains (different subnets)...so we wouldn't
> have to do all that L2 stuff
>
> -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

[quinn snyder]

the challenge is that when you tout your vm mobility play as “zero touch” after 
move (i.e. you don’t have to re-ip your vm/application/etc to ensure 100% 
business continuity) — you need to have stretched layer-2 between locations to 
ensure proper functionality.
things like bgp host-route injection or dns-gslb can remove the dependence on 
application == ip address — but the organization has to be mature enough to 
handle such things — especially in an automated way.
hence the evolution of things like lisp and vxlan within the enterprise/dc — to 
help alleviate some of these problems (i.e. we can do a layer-2 overlay on a 
layer-3 network).  while mpls does such things as well — for a long time — the 
requirements for dc have diverged from service provider.  this is slowly 
changing.

q.
--
quinn snyder | snyd...@gmail.com


> On 1 Feb, 2018, at 10:04, Aaron Gould  wrote:
>
> So I think (I could be wrong as I'm not a server guy) that all this L2
> network emulation is because of server virtualization and moving vm's or
> vmotion or something like that, and that they need to be in same ip subnet
> (aka bcast domain) correct ?
>
> *if* that's true, and *if* all this layer 2 networking madness is because of
> that point stated above, I would think that someone (vendors/standards
> bodies/companies) would/should be working really hard to make that server
> stuff work in different bcast domains (different subnets)...so we wouldn't
> have to do all that L2 stuff
>
> -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/



signature.asc
Description: Message signed with OpenPGP
___
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

[Mario Ruiz]

The only reason for this is because some vendors do not want learn tcp/ip
just so they can force their own customer support on others. So they don't
want to deal with it and sell you on layer 2.

Mario

On Feb 1, 2018 2:02 PM, "Aaron Gould"  wrote:

> As my teenage son would say. "bet" !
>
> -Aaron
>
> --
>
> Heck yeah, pair of cheapest asr920 at each end and PWs between the DCs and
> you're done.
>
> adam
>
> ___
> 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/
>
___
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

[Aaron Gould]

As my teenage son would say. "bet" !

-Aaron

--

Heck yeah, pair of cheapest asr920 at each end and PWs between the DCs and 
you're done.

adam

___
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

[Aaron Gould]

So I think (I could be wrong as I'm not a server guy) that all this L2
network emulation is because of server virtualization and moving vm's or
vmotion or something like that, and that they need to be in same ip subnet
(aka bcast domain) correct ?

*if* that's true, and *if* all this layer 2 networking madness is because of
that point stated above, I would think that someone (vendors/standards
bodies/companies) would/should be working really hard to make that server
stuff work in different bcast domains (different subnets)...so we wouldn't
have to do all that L2 stuff

-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

[adamv0025]

> Richard Clayton
> Sent: Thursday, February 01, 2018 9:30 AM
> To: Cisco NSPs
> Subject: Re: [c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue
> 
> Hi
> 
> I ended up dumping the OTV design for my customer as it was too expensive
> to deploy.  It's only supported on the 4451 (customer has been quoted for
> 4431) and needs and AppX license, was looking at £9000+ per router and
> there is a built in 100Mb limit on OTV traffic.  I'm doing VPLS now but was
> good to play with OTV in a lab environment.  May come across it one day out
> in the wild.
> 
Heck yeah, pair of cheapest asr920 at each end and PWs between the DCs and 
you're done.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
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

[adamv0025]

> Aaron Gould [mailto:aar...@gvtc.com]
> Sent: Tuesday, January 30, 2018 6:30 PM
> 
> Thanks
> 
> "With regards to the load-sharing in L2
>  -problem is you'll never get IP like load-sharing in L2 since Ethernet is
> fundamentally flawed in this regard as it just can't associate same mac
> address with two ports."
> 
> I thought with bgp-mac-routes in evpn, you could engineer traffic with
same
> knobs used in bgp-ip-routes. ?
> 
> I thought with evpn, you could have active-active multi-homed forwarding
> across 2 ports, 2 CE's. ?
> 
Well yes once in MPLS core you can do all sorts of things, 
But try this setup:
CE1-SW1-PE1/2---P---PE3/4-SW2-CE2

For example SW1 would go crazy if learning CE2's mac address on port to PE1
as well as on port to PE2.
Now replace SW1 with your favourite DC overlay infrastructure and the same
thing happens. 
Even if you remove SW1 out of the equation you get the same end result it
now just becomes CE1's problem.

If SWs in the above example where L3 devices or L3 networks and CE1 and 2
communicating at L3 you'd get true per flow load-sharing.

The only solution to this is to fool SW1 (or CE1 if there's no SW) to think
that link to PE1 and link to PE2 is actually the same single link (bundle
link) -that's the MC-LAG magic -but that works for a simple setup but not
for a large DC with 2x2 geo-redundant exits. 
Otherwise you're left with per VLAN load-sharing at most. 
  

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
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

[Gert Doering]

Hi,

On Thu, Feb 01, 2018 at 09:30:20AM +, Richard Clayton wrote:
> I ended up dumping the OTV design for my customer as it was too expensive
> to deploy.  It's only supported on the 4451 (customer has been quoted for
> 4431) and needs and AppX license, was looking at £9000+ per router and
> there is a built in 100Mb limit on OTV traffic.  I'm doing VPLS now but was
> good to play with OTV in a lab environment.  May come across it one day out
> in the wild.

Nothing better than "make it silly expensive" to kill a proprietary
technology that could be used for "happy customer lock-in" instead.

Big company strategical planning is beyond me...

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

[Richard Clayton]

Hi

I ended up dumping the OTV design for my customer as it was too expensive
to deploy.  It's only supported on the 4451 (customer has been quoted for
4431) and needs and AppX license, was looking at £9000+ per router and
there is a built in 100Mb limit on OTV traffic.  I'm doing VPLS now but was
good to play with OTV in a lab environment.  May come across it one day out
in the wild.

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/

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

[James Bensley]

On 30 January 2018 at 18:29, Aaron Gould  wrote:
> Thanks
>
> "With regards to the load-sharing in L2
>  -problem is you'll never get IP like load-sharing in L2 since Ethernet is
> fundamentally flawed in this regard as it just can't associate same mac
> address with two ports."
>
> I thought with bgp-mac-routes in evpn, you could engineer traffic with same
> knobs used in bgp-ip-routes. ?
>
> I thought with evpn, you could have active-active multi-homed forwarding
> across 2 ports, 2 CE's. ?
>
> -Aaron

Hi Aaron,

That is correct. EVPN does support multi-active forwarding with a
single designated forwarding PE for BUM traffic. It's "closer" to a
typical L3 VPN in that the customer MAC addresses (instead of IP
prefixes) are learnt in the control-plane. If using BGP for example as
your control-plane, ECMP now becomes an option because you have
multiple MAC routes in BGP, each with a different next-hop and label
(if using MPLS based EVPN). This is the same as a dual-homed CPE in a
L3 VPN. MACs are stored in a MAC-VRF like an IP VRF and each MAC-VRF
has a unique route distinguisher, also like an IP VRF.

It's easy to get caught up in new jazzy technologies but I do really
like EVPN [1] because L2 VPNs and L3 VPNs start to operate with more
similar properties.

Cheers,
James.


[1] We don't have any live EVPN yet, I'm just lab testing it at
present to better understand it.
___
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

[quinn snyder]

This has been standard n7k operations since the platform
supported contexts. 
Much like ASA — interfaces need to be dedicated to a context from the 
management-plane perspective. 

OTV requires a separate context due to inability to have SVI and OTV in same 
context. OTV essentially becomes a part of the L2 domain on the inside — and L3 
domain on the outside sending encap’d traffic. 

q. 

--
quinn snyder | snyd...@gmail.com

-= sent via iphone. please excuse spelling, grammar, and brevity =-

> On Jan 30, 2018, at 11:33, Aaron Gould  wrote:
> 
> Ha, thanks Justin, I just read the answer to my question I just posted...
> OTV is cisco proprietary.  Is OTV gaining steam in the industry as a
> potential ietf standard ?
> 
> Interesting things you mention about assigning asics, and linecard
> dependancies...
> 
> -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/
___
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

[Aaron Gould]

Ha, thanks Justin, I just read the answer to my question I just posted...
OTV is cisco proprietary.  Is OTV gaining steam in the industry as a
potential ietf standard ?

Interesting things you mention about assigning asics, and linecard
dependancies...

-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

[Aaron Gould]

Thanks, so is OTV cisco proprietary ? 

-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

[Aaron Gould]

Thanks

"With regards to the load-sharing in L2
 -problem is you'll never get IP like load-sharing in L2 since Ethernet is
fundamentally flawed in this regard as it just can't associate same mac
address with two ports."

I thought with bgp-mac-routes in evpn, you could engineer traffic with same
knobs used in bgp-ip-routes. ?

I thought with evpn, you could have active-active multi-homed forwarding
across 2 ports, 2 CE's. ?

-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

[adamv0025]

Hey,

> Aaron Gould
> Sent: Monday, January 29, 2018 7:08 PM
> 
> 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.
> 
While on it you might as well read about the rest of the family
(Fabric-Path, TRILL, 802.1ah PBB and naturally PBB-EVPN) so you get the full
picture. (so we basically have MAC-in-MAC, MAC-in-IP, MAC-in-MPLS)

Fabric-Path, TRILL, VXLAN are mostly used within the DC.  
- to facilitate load-sharing and as a result better use of available DC
switch fabric capacity. 
While OTV, VPWS, VPLS, EVPN, PBB, PBB-EVPN are used for DC-Interconnect. 
- to connect DC at L2 basically building huge L2 domains (all that just so
that the VMware VMotion can work between DCs -sad, init?)
- but SPs found another use case for some of these and that is Carrier
Ethernet services and the whole MEF umbrella. 

And then there's the whole fun around stitching the Intra-DC protocols to
the Inter-DC protocols while maintaining load-sharing and avoiding loops. 

If I was building a green field DC my first choice would be NCS5k or QFX5k
-so that I have traffic engineering and SDN capabilities within the DC in
order to be able to better distribute elephant flows around the fabric and
as a bonus I'd get seamless integration with the MPLS core (same transport
technology in access, aggregation, core, DC and an end-to-end control via
common controller).

With regards to the load-sharing in L2
 -problem is you'll never get IP like load-sharing in L2 since Ethernet is
fundamentally flawed in this regard as it just can't associate same mac
address with two ports. 
  
adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
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

[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

[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

[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

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

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

[Richard Clayton]

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