gewoon, mijn archief
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/lxvpn/configuration/guide/lesc51x/lesc51p2mps.html#68334
http://www.brianraaen.com/2012/01/17/setting-up-802-q-and-switch-ports-in-an-asr9000/
http://www.warisinfo.com/technology-tutorials
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
Release Notes for the Cisco ASR 900 Router
http://www.cisco.com/c/en/us/td/docs/routers/asr903/release/notes/asr903_3S_rel_notes.html
http://www.cisco.com/c/en/us/products/collateral/routers/asr-903-series-aggregation-services-routers/data_sheet_c78-715296.html
“Cisco IOS XE on Cisco ASR 920 Series Router (ASR-920-24SZ-IM) supports upgradeable firmware for field programmable hardware devices such as interface modules (IMs) and upgrades IM FPGA when ever there is an upgrade.”
ASR920 FPGA version support is explained a little more here; http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/intro.html
show facility-alarm status
System Totals Critical: 0 Major: 0 Minor: 0
> It seems quite scalable and seems to have a nice path to higher
> density ethernet with the RSP3 supporting (8) 10 gig, (2) 40 gig and
> (1) 100 gig
Yea, the 10G port density is pretty awesome with RSP3. 100Gig IMA requires CPAK though.
>
> What do y’all know about this 902,903,907 ? I want it for my
> distribution/aggregation of L2 and L3, vpls (manual and bgp ad), vpnv4
> and future vpnv6.
Right now, we roll 903, 902 and 920s for simple L2 Metro-E backhaul, nothing fancy and it works really well for us. We also use it for VPLS and no problem there either.
The only caveat we ran into is lack of hash options for LACP/port-channels. Not really easy to load-balance if a subscriber has LACP’d bundle into one of these. There is no support for 5-tuple hash, nor MPLS label hash like on Cat65/68k Sup2T or ASR 9k series on bundles; you only get src-dst IP/mac.
Lastly, (it’s not really ASR 90x problem) it uses IOS XE, which means if you are running 6PE and have ASR 90x in the label switching path, it will reply to IPv6 traceroute with FFFF::ipv4, instead of using IPv6 address you have configured in the transiting interfaces on the box. We typically configure IPv6 interface on core interfaces, even if we’re running 6PE and have no IPv6 routing protocols in the core.
On IOS XR, NXOS and JUNOS, P routers in the path will always pick the configured interface IPv6 address to respond to v6 traceroute; IOS XE and Classic will always pick FFFF::ipv4 and it’s quite annoying as it breaks traceroute on several operating systems (i.e. FreeBSD) that conform to RFC which does not permit FFFF:: from the wire.
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.
Only 2 VLAN translate operations (1:1 and 2:1, pop:push) are supported on ASR 920, it was introduced in 3.16 release. Prior to 3.16 no translations were supported.
rewrite ingress tag pop 1 symmetric
rewrite ingress tag pop 2 symmetric
rewrite ingress tag push dot1q <TAG> symmetric rewrite ingress tag translate 1-to-1 dot1q <TAG> symmetric rewrite ingress tag translate 2-to-1 dot1q <TAG> symmetric
>
> Nice that’s clever.
> And since you are using CSR1000v you don’t need to worry about the
> cost of HW for RRs.
Yes, the CSR1000v’s are workhorses.
> I see, so RRs do the routing decision on behalf of the PE routers in a
> particular PoP.
Correct, but in some cases, the routing decision is done in a completely different country/continent/cluster, before that final decision is pushed down to the RR which has the target edge router. Either way, the result is always the same, since the destination traffic was headed toward that different country/continent anyway.
> Since RR cluster is local to the PoP the AS-exit proximity is
> accurate, in other words what is good for the RR has to be good for
> the PEs within the PoP.
Yes, and this is a very important point that you note. Having iBGP sessions to RR’s not in the same physical PoP can lead to sub-optimal routing for devices in that PoP, as by default, RR’s base best-path selection for IGP metrics on the local IGP metric, while the iBGP neighbor would be remote.
BGP-ORR, covered in “draft-ietf-idr-bgp-optimal-route-reflection-09”, is trying to fix this. But I don’t know of anyone shipping code yet.
> But still you’d have to use add-path to advertise backup paths from
> RRs to PEs in a local PoP whereas with MP-BGP you’d just use unique RDs.
You might find it strange but I do neither :-).
Each cluster has 2x RR’s. Each iBGP client has 2x sessions to each RR for all address families.
Based on our hardware, we’ve modeled convergence performance for BGP routing and found it to be reasonably quick across the network.
Considering the additonal overhead Add-Paths and such would bring, it has been a calculated decision to keep things simple, and rely on Next-Hop Address Tracking tech. in Cisco and Juniper to speed up convergence. BFD for IS-IS has also been very helpful, as we’ve found BGP to be a lot more stable in a steady-state.
We are still watching this, and will decide if physically installing additional paths is a good idea. For now, it’s not hurting overall network performance.
>
>
> I see it as more of a good practice not to hold default route or full
> inet table on a peering box but as I said before peer pointing a
> default at you is rather a corner case I guess.
Hehe, depends. Some folk point default toward you at peering points because they don’t know better. Others do because they are chancers.
Either way, avoid the risk.
We have dedicated peering routers in each PoP. We carry neither a full table nor a default route on those. In fact, we null-route default routes on every peering box.
>
>
> Yeah been doing EoMPLS PW to provide full internet feed to customers
> behind MEs didn’t have the confidence to use the table-map/SRD 🙂
You should try BGP-SD, works great over here :-).
Tunnels or eBGP-Multihop is too much for me for passing full feeds to customers :-).