About xthuijs

xthuijs · ‎09-11-2018

you can only "strip" the username or format it. if you dont care about the "@-domain" part then you can use the : username-strip prefix-delimiter - cheers xander

xthuijs · ‎07-16-2018

that is possibly too! say you have a route-policy defined like this: route-policy RTshow if extcommunity rt (x:y) then pass endif you can do show bgp vrf RED route-policy RTshow xander

xthuijs · ‎07-16-2018

you can check the bgp prefix to see what the RD and RT's are, example below. also you can filter the routes import at the vrf address family level with a route-policy import rule. xander RP/0/RSP0/CPU0:A9K-BNG#show bgp vrf RED 22.1.1.1/32 Mon Jul 16 12:39:17.766 EDT BGP routing table entry for 22.1.1.1/32, Route Distinguisher: 10.86.188.99:0 Versions: Process bRIB/RIB SendTblVer Speaker 18 18 Last Modified: May 14 07:22:21.564 for 9w0d Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer Local 131.1.1.2 from 131.1.1.2 (2.2.2.2) Received Label 24002 Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 0, version 18 Extended community: RT:10:10 RT:100:100 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 2.2.2.2:0

xthuijs · ‎06-12-2018

hi sam, I think you're mixing a few things here that can't work together. What works is, or what goes together is: - BNG, amb vlan and dhcp profile (proxy). - PWHE means xconnect between PW on one leg and a pwhe interface on the other leg. OR - bridge domain, vfi's (or not), pseudo wire, attachment circuits - if you add dhcp snooping to the BD, you must have explicit vlan configuration snooping does not track the vlan combo for hte incoming session like a BNG access interface does. so while you can take the discover and RELAY it, the return path doesnt exist since dhcp relay doesnt know what vlan combo to inject the packet into the BD with. so your findings are consistent with the operations of the protocols/device implementation. xander

xthuijs · ‎06-08-2018

ah ok I see allen, yeah this is currently not a supported feature in PBR. doing this in the hardware forwarding path is doable, but tricky, besides the ttl, the checksum needs to be updated as well. I assume that it needs to be done conditionally for some traffic categories only? If you have an external device that has that capability, then you could possibly leverage PBR to redirect traffic to that device, modify TTL and continue to route from there? cheers xander

xthuijs · ‎06-05-2018

this is probably not the complete pppoe debugging log right? I am missing the PADI reception and the PADO from the router sent and the PADR confirmation from the client. what does stand out is that the PADS was sent upon which after 30 seconds a PADT is received. it smells to me that the client never received the PADS in that case. after PADS for the BNG, it would start to send LCP confreq messages, it looks like the client is not seeing any of that. debug pppoe protocol debug pppoe packet is helpful as well as debug ppp nego if the client has some debugging capabilities, seeing some logs from that end would be helpful also. confirm with a wireshark that the messages are hitting the line too. also since you are using LC based subscribers make sure your release in question is adequate to support that. regards xander

xthuijs · ‎06-05-2018

that is interesting! yeah sorry there is no configuration today that can rewrite the TTL of the packets. every router is supposed to decrement by one, not adding it :) in fact sounds sort of dangerous too, because if there is a routing loop one could infinitely loop packets around without stopping... xander

xthuijs · ‎06-05-2018

hi sam, another option is to use PWHE. this way you instead of bundling 2 tags into a single tag on the adj pre-agg node, you'll make a PW there. and you map your S-tag as a PW say, and use the inner/outer that is originally there. so basically if you have a frame that looks like: ur(S-tag) - their(S-tag) - their(C-tag) then do: rewrite ingress tag pop 1 symmetric on the EFP side and xconnect it into a pw with VCid ur(S-tag) you can build multiple PW's between pre-agg and bng. for now using PWHE eliminates the use of GEORED, but that is coming, but you can also use PW redundancy in the interim. also PWHE binds you to RP based session scale. xander

xthuijs · ‎04-06-2018

This document applies to NCS5500 and ASR9000 routers and has been verified as such. Introduction traditional ECMP or equal cost multipath loadbalances traffic over a number of available paths towards a destination. When one path fails, the traffic gets re-shuffled over the available number of paths. This means that a flow that was before taking path "1", could now be taking path "3" although only path "2" failed. This reshifting occurs because the hash of althogh the flow remains the same resulting in the same bucket, but the bucket may get reassigned to a new path. To understand flows, buckets and traditional ECMP a bit better, you could reference the Loadbalancing Architecture document and consult the Cisco Live ID 2904 from Las Vegas 2017. While this flow redistribution is not a problem in traditional core networks, because the end to end connectivity is preserved and the user would not experience any situation from it, in data center loadbalancing this can be a problem. Datacenter loadbalancing This rehashing as mentioned can be troublesome in data center environments where many servers advertise a "service prefix" to a loadbalancer/gateway in a sort of "anycast" way. This results in a user connecting with its l3/l4 tupple would be delegated to one particular server for a session. If for whatever reason a server fails, we don't want the established session to a server to be rehashed to a new server as that will reset the tCP connection sicne that new server may have no clue (~socket :) about this session it just got a packet for. To visualize: Persistent Loadbalancing or Sticky ECMP defines a prefix in such a way that we dont rehash flows on existing paths and only replace those bucket assignments of the failed server. The good thing is that established sessions to servers wont get rehashed. The downside of this is that you could see more load on one server then another now. (Traditional ECMP would try to achieve equal spread, at the cost of that rehashing). Implementation details How to map prefixes for sticky ECMP ? Use an RPL to define prefixes that require persistent load balancing. User would match some BGP community to set sticky ecmp flag What happens when a path in an ECMP goes down ? In FIB each prefix has a path list, say for example a prefix ‘X’ has a path list (p1, p2, p3) and when a path say ‘p2’ fails with sticky ECMP enabled new path list become (p1, p1, p3), instead of the default rehash logic, which results (p1, p3, p1) What happens when a link comes back ? There are 2 modes of operation: DEFAULT: No rehashing is done and the link will not be utilized until one of the following happens, which results a complete recalculation of paths. New path addition to ECMP. User driven clear operation using “clear route” command. CONFIGURABLE: Auto recovery. If the server comes back or the path gets reenabled, we automatically reshuffle the sessions, this will result in sessions that were moved from the failed path to a new server will now be rehashed BACK to the original server that got back online, this will result in session disruption ONLY for those sessions. There is no one size fits all answer here hence we provide the 2 options: manual recovery or automatic recovery, with both pros and cons. Configuration Now that you're all excited about this new functionality, you want to try it out right? here is the configuration sequence on how to establish it: First define the route policy that will direct which prefixes are to be marked as sticky. route-policy sticky-ecmp if destination in (192.168.3.0/24) then set load-balance ecmp-consistent else pass endif end-policy Apply that route policy to BGP through the table-policy directive: router bgp 7500 address-family ipv4 unicast table-policy sticky-ecmp maximum-paths ebgp 64 maximum-paths ibgp 32 ! need to have multipath enabled obviously That's it! Verification of operation Let's verify the CEF display before a failure occurred: Show cef <prefix> detail LDI Update time Sep 5 11:22:38.201 via 10.1.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080] path-idx 0 NHID 0x0 [0x57ac4e74 0x0] next hop 10.1.0.1/32 via 10.1.0.1/32 via 10.2.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080] path-idx 1 NHID 0x0 [0x57ac4a74 0x0] next hop 10.2.0.1/32 via 10.2.0.1/32 via 10.3.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080] path-idx 2 NHID 0x0 [0x57ac4f74 0x0] next hop 10.3.0.1/32 via 10.3.0.1/32 Load distribution (persistent): 0 1 2 (refcount 1) Hash OK Interface Address 0 Y GigabitEthernet0/0/0/0 10.1.0.1 1 Y GigabitEthernet0/0/0/1 10.2.0.1 2 Y GigabitEthernet0/0/0/2 10.3.0.1 we see 3 paths identified with 3 next hops (10.1/2/3.0.1) via 3 different gig interfaces. We can also see here that the stickiness is enabled through the "persistent" keyword. After a path failure, in this example we brought gig 0/0/0/1 down: Show cef <prefix> detail LDI Update time Sep 5 11:23:13.434 via 10.1.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080] path-idx 0 NHID 0x0 [0x57ac4e74 0x0] next hop 10.1.0.1/32 via 10.1.0.1/32 via 10.3.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080] path-idx 1 NHID 0x0 [0x57ac4f74 0x0] next hop 10.3.0.1/32 via 10.3.0.1/32 Load distribution (persistent) : 0 1 2 (refcount 1) Hash OK Interface Address 0 Y GigabitEthernet0/0/0/0 10.1.0.1 1* Y GigabitEthernet0/0/0/0 10.1.0.1 2 Y GigabitEthernet0/0/0/2 10.3.0.1 Notice the replacement of bucket 1 with gig 0/0/0/0 and the "*" denoting that this path is a replacement as it took a hit before. We keep the bucket sequence in tact, we jsut replace it with an available path index. Note that this will keep this way irrespective of gig0/0/0/1 coming back alive. To recover the paths and put gig0/0/0/1 back in service on the hashing use: clear route <prefix> Auto recovery To enable the auto recovery, confgure cef consistent-hashing auto-recovery A full trace sequence is given here with some show commands and verification: RP/0/RSP0/CPU0:PE1#sh run | i cef Building configuration... bgp graceful-restart cef consistent-hashing auto-recovery RP/0/RSP0/CPU0:PE1#sho cef 192.168.3.0/24 detail 192.168.3.0/24, version 674, internal 0x5000001 0x0 (ptr 0x722448fc) [1], 0x0 (0x0), 0x0 (0x0) Updated Nov 4 08:14:21.731 Prefix Len 24, traffic index 0, precedence n/a, priority 4 BGP Attribute: id: 0x6, Local id: 0x2, Origin AS: 0, Next Hop AS: 0 ASPATH : Community: gateway array (0x72ce5574) reference count 1, flags 0x2010, source rib (7), 0 backups [1 type 3 flags 0x48441 (0x72180850) ext 0x0 (0x0)] LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Nov 4 08:14:21.731 LDI Update time Jan 1 21:23:30.335 Level 1 - Load distribution (consistent): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [0] via 12.4.18.2/32, recursive [1] via 12.5.19.2/32, recursive [2] via 12.6.20.2/32, recursive [3] via 12.101.45.2/32, recursive [4] via 12.104.46.2/32, recursive [5] via 12.105.47.2/32, recursive [6] via 12.106.49.2/32, recursive [7] via 12.107.43.2/32, recursive [8] via 12.111.48.2/32, recursive [9] via 12.112.44.2/32, recursive [10] via 12.122.18.2/32, recursive [11] via 12.150.16.2/32, recursive [12] via 12.151.17.2/32, recursive [13] via 12.152.9.2/32, recursive [14] via 12.153.23.2/32, recursive [15] via 12.154.0.2/32, recursive RP/0/RSP0/CPU0:PE1#cle counters a Clear "show interface" counters on all interfaces [confirm] RP/0/RSP0/CPU0:Jan 1 21:25:20.059 PDT: statsd_manager_g[1167]: %MGBL-IFSTATS-6-CLEAR_COUNTERS : Clear counters on all interfaces RP/0/RSP0/CPU0:PE1#LC/0/1/CPU0:Jan 1 21:25:28.050 PDT: ifmgr[215]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/1/0/5/0, changed state to Down LC/0/1/CPU0:Jan 1 21:25:28.050 PDT: ifmgr[215]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface TenGigE0/1/0/5/0, changed state to Down RP/0/RSP0/CPU0:PE1#show int tenGigE 0/1/0/5/0 ac TenGigE0/1/0/5/0 Protocol Pkts In Chars In Pkts Out Chars Out IPV4_UNICAST 1 59 98123 96355844 RP/0/RSP0/CPU0:PE1#cle counters Clear "show interface" counters on all interfaces [confirm] RP/0/RSP0/CPU0:Jan 1 21:25:38.896 PDT: statsd_manager_g[1167]: %MGBL-IFSTATS-6-CLEAR_COUNTERS : Clear counters on all interfaces RP/0/RSP0/CPU0:PE1# RP/0/RSP0/CPU0:PE1#LC/0/1/CPU0:Jan 1 21:25:43.353 PDT: pfm_node_lc[302]: %PLATFORM-CPAK-2-LANE_0_LOW_RX_POWER_ALARM : Set|envmon_lc[163927]|0x1005005|TenGigE0/1/0/5/0 RP/0/RSP0/CPU0:PE1#LC/0/1/CPU0:Jan 1 21:25:50.110 PDT: ifmgr[215]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/1/0/5/0, changed state to Up LC/0/1/CPU0:Jan 1 21:25:50.110 PDT: ifmgr[215]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface TenGigE0/1/0/5/0, changed state to Up RP/0/RSP0/CPU0:PE1#show int tenGigE 0/1/0/5/0 ac TenGigE0/1/0/5/0 Protocol Pkts In Chars In Pkts Out Chars Out ARP 1 60 1 42 RP/0/RSP0/CPU0:PE1#show int tenGigE 0/1/0/5/0 ac TenGigE0/1/0/5/0 Protocol Pkts In Chars In Pkts Out Chars Out IPV4_UNICAST 0 0 24585 24142470 ARP 1 60 1 42 RP/0/RSP0/CPU0:PE1#sho cef 192.168.3.0/24 detail 192.168.3.0/24, version 674, internal 0x5000001 0x0 (ptr 0x722448fc) [1], 0x0 (0x0), 0x0 (0x0) Updated Nov 4 08:14:21.731 Prefix Len 24, traffic index 0, precedence n/a, priority 4 BGP Attribute: id: 0x6, Local id: 0x2, Origin AS: 0, Next Hop AS: 0 ASPATH : Community: gateway array (0x72ce5fc4) reference count 1, flags 0x2010, source rib (7), 0 backups [1 type 3 flags 0x48441 (0x721807d0) ext 0x0 (0x0)] LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Nov 4 08:14:21.731 LDI Update time Jan 1 21:25:53.128 Level 1 - Load distribution (consistent): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [0] via 12.4.18.2/32, recursive [1] via 12.5.19.2/32, recursive [2] via 12.6.20.2/32, recursive [3] via 12.101.45.2/32, recursive [4] via 12.104.46.2/32, recursive [5] via 12.105.47.2/32, recursive [6] via 12.106.49.2/32, recursive [7] via 12.107.43.2/32, recursive [8] via 12.111.48.2/32, recursive [9] via 12.112.44.2/32, recursive [10] via 12.122.18.2/32, recursive [11] via 12.150.16.2/32, recursive [12] via 12.151.17.2/32, recursive [13] via 12.152.9.2/32, recursive [14] via 12.153.23.2/32, recursive [15] via 12.154.0.2/32, recursive Restrictions and limitations Sticky load balancing is more resource intensive operation so it is not advised to enable it for all prefixes. Only supported for BGP prefixes Sticky ECMP is available in XR 6.3.2 for NCS5500 and ASR9000 Auto Recovery is available in XR 6.5.1

xthuijs · ‎04-06-2018

hi! note this is the XROS and platforms forum and we may not have all the knowledge about ISR/XE, but I can get you porbably started in the right direction. the ISR443 is built with dual CPU and multicore. some of the cores are handing control plane and some of the cores handle the data plane forwarding. since this is effectively parallel software forwaridng that means that a packet requiring more service will automatically take longer. sequencing is normally maintained, but it can happen that one packet being done faster is getting sent faster also this in order to maintain proper forwarding power so that one clogging core taking more time to process doesnt stall the pipeline for others that can be done quicker. so I can understand this situation you are seeing. espeically considering you mention "tunnl". if the frag is on the outer the tun dest needs to reassemble and reassembly in any forwarding especially with multi packet processing is a disaster! eg second frag can come in on different core! so pak has to be placed on a public palce for all to grab to reassemble. the inner frag is reassembled by the host obviously. in general it is always best to prevent frag as much as possible because of all the stipulations that it comes with take loadbalancing for example: with a frag packet I cant hash on the L3/L4, so I need to inspect the L3 header for frag offset or MF to exclude or update hash from L4 info since non zero frags dont have an l4 header... some implementations dont perceive that and can cause different LB decissions for the first frag and subsequent ones... some other implementations dont reassemble in the fast path or frag in thr fastpath and that can also cause processing delays or features not getting applied. xander

xthuijs · ‎02-12-2018

Introduction With XR 4.2.0 the ASR9000 is releasing a new line of hardware models. This amongst others is the RSP440, the next generation RSP with faster switch fabric along with Typhoon based Linecards, the next generation network processor. Explanation In the TAR file from CCO there are files like asr9k-mini-p.pie or asr9k-mini-px.pie. The reason why there are 2 sets of files is because there are 2 hardware versions of the RSP. The RSP2, the "old" RSP is based on a dual core PPC. The new RSP440 has an 4 core Intel processor. Because PPC and INTEL handle endians differently, there are compiler differences to generate sw for the different PPC and the INTEL. Features and functionality are the same between RSP2 and RSP3. Scale might be different. The trident based linecards (2T20G, 40GE, 4T, 8T, 8T/4) as well as the new typhoon linecards (24x10GE, MOD80, MOD160, 100G) are all PPC based. What that means is that Only when you have an RSP3 in your system, you need to load the PX images. When you have an RSP2 based system you need to load the P images. The precense of a Trident or Typhoon linecard doesn't matter. So an RSP2 with a typhoon LC, still runs the -p images. When you are upgrading from RSP to RSP440, this can't be done "hot". RSP2 and RSP440 can't coexist in the same system. This simple table helps in the selection process, note that this applies for XR 4.2.0 and later. RSP RP CPU type Linecard Trident Based (PPC) Typhoon Based (PPC) Tomahawk Based (x86) ASR9001 PPC N/A P N/A RSP2 PPC P P N/A RSP440 x86 PX PX PX RSP880 x86 N/A PX PX

xthuijs · ‎02-12-2018

I am sure you are all familiar with the difference between P and PX images that are seen on CCO for the ASR9000. If not, read this https://supportforums.cisco.com/t5/service-providers-documents/asr9000-xr-what-is-the-difference-between-the-p-and-px-files/ta-p/3329745 With XR 4.3.0 we are making some changes to the file packaging and from that release on, we only provide the PX version which is useable on both the RSP2/ASR9001 and RSP440. This will simplify the SMU delivery as well as the complexity of managing multiple images. Note that in order to run XR 4.3.0 combo image, you may need to upgrade the rommon of your 9022 and RSP440 to a minimum of rommon 0.61 if you do a turboboot. If you don't do turboboot (that is running release X and upgrading to 4.3.0 with the mini-pie the rommon update is not a requirement for boot. As always your FPD's need to be up to date after the upgrade, please

xthuijs · ‎02-09-2018

hi mike, yes that is possible. if you make bundles between the 2 LC's, you can carry 64k sessions, 32k per npu and have bundle redundancy between the 2 lc's. xander

xthuijs · ‎01-10-2018

hi mg, the key thing to the "lite" module is the fact that it has lesser transmit power then the "full" version. the rated distance is upto 25km. for the full version that can go upto 40km it is required to run (e)FEC to enhance the signal interpretation and using correction algorithms. it also depends on what FEC mode you use and the chipset of the card that is or is not able to enhance the signal. this picture shows a bit what FEC can do for the signal enhancement. note that the ipodwdm card for asr9k has a special cisco chip (ETNA) that can improve long haul transmissions. xander

xthuijs · ‎01-08-2018

hi lorenzo! I am not in tune with asr1k licensing, but I forwarded your question/link to the product management group for this platform to see if they can rewview and respond to your inquiry! cheers xander

Date Registered	‎04-06-2010 07:50 AM
Date Last Visited	‎09-19-2018 10:01 AM
Total Messages Posted	1,322
Total Helpful Votes Received	1644

Re: BNG AAA attribute format string

Re: BGP VPNV4 Routes in XR

Re: BGP VPNV4 Routes in XR

Re: BNG AAA attribute format string

Re: XR Ttl Change

Re: ASR9000-BNG Sessions PPPoE does not...

Re: XR Ttl Change

Re: BNG AAA attribute format string

XR:NCS5500/ASR9000 Persistent Loadbalan...

Re: ISR 4431 out or order Fragmented Pa...

ASR9000/XR What is the difference betwe...

ASR9000 XR 4.3.0 important change

Re: BNG deployment scale guidelines on ...

Re: Cisco CPAK 100GBASE-ER4 Lite Module

Re: ASR1001-x licensing