Cisco switches don’t just look at the last x bits, they use a proprietary algorithm to do the hashing. I don’t have the liberty to provide details, however I can confirm that it’s an actual algorithm and not just “last x bits”. The following document confirms too:

http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html

L2TPv3 works fairly well (better than I expected). I did some lab testing on it last year before deploying it for a customer where I had no other choice. I’d always pushed it to the side in favour of MPLS pseudowires and prior to last year I had only used it where I had to and the requirement was minimal (minimal traffic volume).

 

Last year I had a customer than needed multiple 100Mbps L2 links for backing up data using a layer 2 application/service. Any typical Cisco

ISRG2 like will process L2TPv3 in hardware so I dropped some 1941’s in and it “just worked”. They max out their 100Mbps fibres ever night with L2TPv3 tunnels between sites.

 

If you use port based L2TPv3 tunnels on the built in interfaces they do support the forwarding of layer 2 control frames too, so spanning-tree, CDP, LAG/LACP, UDLD etc also work. I’m now about to deliver this again possibly with 2921s for higher throughput for another customer and this customer will be runing STP or LACP, we’ve tested both in the lab and the different failure scenarios and it all “just works”. They can just add additional VLANs on their switch trunks facing the 2921s and extend extra VLANs between sites without input from me, port based if ignorant and just transport whatever it recieves.

 

My only gripe is no layer 2 QoS.

http://null.53bits.co.uk/index.php?page=mst-refresh

 

http://null.53bits.co.uk/index.php?page=l2tpv3-port-based-xconnect

 

http://null.53bits.co.uk/index.php?page=l2tpv3-rpw

 

I did some testing with bridges too when spanning tree is present, as I don’t normally use them in such a scenario. You may need to use bridges in a scenario where you are extending layer 2 through something like an ISR-G2, IRB does interfere so it’s no advised:

http://null.53bits.co.uk/index.php?page=l2-bridging

 

Cheers,

James.

Cheers,

James.

It was changed in 12.2(33)SXH – when the PFC hits exception on TCAM, it’ll switch “exception” packets (packets to destination that’s outside of known TCAM programmed entries) with a mls hardware-limiter set to 10kpps

Related to TCAM reallocation, make sure the SP bootvar’s config register matches the RP bootvar’s config register. In tech-speak, ‘sh bootv | i eg’ should match ‘rem com sw sh bootv | i eg’.

If it doesn’t, “conf t; config-register 0x2142; end; conf t; config-register 0x2102; end; copy run start” and recheck. A mismatch in how the SP pre-configures itself is immaterial for the basics of IOS configuration stuff, but fatal with respect to TCAM; the box will forcibly reload after 5 minutes endlessly until fixed.

——

>  IPv4                – 768k

>  MPLS                – 16k (default)

>  IPv6 + IP Multicast – 64k

 

Aim for 64k IPv6 routes (2 byte boundary)

 

I am wanting to get my Cisco ASR9001 talking VXLAN to my Arista Switch.

>

> The Arista VXLAN Unicast VTEP config is EXTREMELY simple.

>

>

> This is the Arista config example:

>

> *Swtich A*

>

> interface Loopback0

>    ip address 1.1.1.1/32

> !

> interface Vxlan1

>    vxlan vlan 100 vni 100000

>    vxlan vlan 100 flood vtep 1.1.1.2

> !

>

> *Switch B*

>

> interface Loopback0

>    ip address 1.1.1.2/32

> !

> interface Vxlan1

>    vxlan vlan 100 vni 100000

>    vxlan vlan 100 flood vtep 1.1.1.1

> !

>

> it is as simple as that.  I would love to have the ASR9001

> participating in the VXLAN of these Arista.

>

> Do you think the feature that was added is compatible with this?

>

I don’t think there is an option to manually define VTEPs.

But that would make sense only in very small deployments.

Because without multicast overlay the BUM traffic has to be unicasted to all VTEPs sharing a common VNI.

 

As Harrold mentioned the last evolutionary step is “VXLAN Network with MP-BGP EVPN Control Plane” (supported only on Nexus9K) where multicast-based data driven flood and learn for remote VTEP peer discovery and remote end-host learning is replaced by MP-BGP EVPN as the control plane for VXLAN so if an end-host is active it’s MAC address is advertised to other VTEPs via MP-BGP so there’s no concept of flooding traffic destined to unknown unicast MAC address. And to reduce broadcast traffic there’s the ARP suppression where the MAC to IP mapping is advertised via MP-BGP between VTEPs.

But even with all these features there’s still a need for multicast overlay to facilitate flooding of other broadcast/multicast traffic within each VNI segment.

 

With regards to EVPN CP for VXLAN on ASR9k To my knowledge ASR9k can only serve as DCI L3 GW (into L3VPN) for an MP-BGP EVPN VXLAN based DC.

So I guess it’s not yet possible to integrate MP-BGP EVPN VXLAN based DC with EVPN or PBB-EVPN based L2VPN backbone which I guess is what all of this is heading towards.