Re: [c-nsp] TIL: Maintenance Operations Protocol (MOP)
--- Begin Message --- On Fri, Aug 06, 2021 at 02:00:30PM +0200, Lukas Tribus wrote: > I'm no longer putting in hundreds of hours to fight losing battles, > which earlier in my carrier I did: > https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/Cisco-SA-20140828-CVE-2014-3347 Ensuring that MOP is dead and stays buried might actually be worth a PSIRT effort - any feature that is on-by-default and enables unauthorized access to a device should be worth the fight. +1, and worth a PSIRT case right away. But it doesn't provide unauthorized access, does it? Drew's test showed a password prompt (not sure what the AAA config looked like).. oli --- End Message --- ___ 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] Cisco vpdn multihop
--- Begin Message --- I am cleaning up a cisco lac/tunnelswich/lns setup historically grown. Do I need the "vpdn multihop" statement on the final LNS which should only terminate the ppp sessions inside the l2tp tunnels and not forward them based on realm/domain-name/... in my setup? One example in cisco's documentation has it on all three Devices while an other has it only on the tunnelswitch. (ok, I could test it in the night the hard way) Thank you for your advice on this, Juergen. Lol, my VPDN skills are, errm, rusty, but I recall the only scenario where you would need vpdn multihop on the final LNS is when you run them in a MPP/SGBP group to terminate multilink-PPP sessions (in which case the final LNS isn't actually final, so this makes perfect sense IMHO) oli --- End Message --- ___ 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] IS-IS as PE-CE protocol
--- Begin Message --- Robert Raszuk wrote: > Hi Victor, > > ISIS has analogy to OSPF down bit integrated if this was your question. Hopefully it is. > But > do check with your implementation to make sure if it supports ISIS leaking. > > PE-CE ISIS is inheriting loop prevention which was defined for ISIS route > leaking between levels in RFC2966 Looks like it. Thank you for the hint! > > " This document redefines this high-order bit in the default metric > >field in TLVs 128 and 130 to be the up/down bit." What would be the Cisco command to enable/disable this feature in IS-IS ? That would be the easiest way to check if the implementation supports it. Last time I checked (and it seems nothing has changed since) IS-IS can't run in a VRF, so you can't use it for MPLS-VPN PE-CE links. IGP support on PE-CE links (like OSPF, EIGRP and RIP [sigh]) has been implemented to enable a seamless transition of typical Enterprise networks from L2 to L3-VPNs. And as ISIS is not a typical Enterprise IGP, it has not been top of mind.. oli --- End Message --- ___ 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] One PE router, one customer, several sites
--- Begin Message --- >Dear Colleagues, > >If a customer's several sites are connected to the same PE router, >but to different interfaces, which is the recommended practice, >assuming that all these sites must be reachable from one another: > >1. Place all the interfaces into the same VRF. > >2. Place each site into a separate VRF and set up route import/export > between the VRFs. > >Thanks in advance for any input. It all depends on your VPN routing policy. If you want all sites to freely communicate between each other, put all of them into the same VRF. If you need to restrict communication (like forcing traffic to a central site/hub), use different VRFs with an appropriate import/export policy. Using different VRFs with an unrestricted import/export policy is IMHO a waste of resources, but your mileage might vary. oli --- End Message --- ___ 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] ISIS Fast Convergence (ASR920?)
> > SPF timers is generally a design decision, so the values above are just > reflecting different design approaches: Choosing an initial wait of 1ms (the > latter settings, i.e. spf-interval 5 1 50) tunes the network for optimal reaction > for link failures, so routers will immediately start to re-route, with the risk of > a subsequent SPF required if the failure was a node failure and additional LSP > updates from other nodes are required to judge this. > Hence a little more conservative setting uses 50msec initial wait, allowing > more LSP updates to come in before the new SPF is calculated.. > > With LFA-FRR, core failures can be handled differently, so a little less > aggressive initial-wait makes a lot of sense in this case.. > > Either way: even without LFA-FRR, difference between 1 and 50 msec is > marginal and not noticeable in practice, so why bother much __ > Agree with Oliver. With any FRR mechanism in place there's absolutely no point in tuning any SPF timers (lowering the timers will just put unnecessary strain on RE CPU) Just would like to point out that in case of iBGP FRR it might be desirable to tune LSP generation and propagation (depending on your SLAs). This is because the "PIC Core" can do its magic only once the ingress router is informed about the failure of the primary egress PE. oli: This is actually PIC-Edge, so even with (LFA-)FRR you want to tune your SPF and LSP timers for PIC-Edge or any other service restoration mechanism to kick in, but 50msec is generally good enough.. oli ___ 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] ISIS Fast Convergence (ASR920?)
Hey, There seem to be some conflicting suggestions for ISIS fast convergence timers, and I can’t seem to understand why that would be. The former example is ISIS in a LFA FRR environment, the latter is from a general best practise guide. I can’t imagine LFA FRR or not would matter to the best practise would it? ASR920 + LFA FRR[1]: spf-interval 5 50 200 prc-interval 5 50 200 lsp-gen-interval 5 50 200 IE: XE 16.5 (Everest) (which can also run on an ASR920)[2]: spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 SPF timers is generally a design decision, so the values above are just reflecting different design approaches: Choosing an initial wait of 1ms (the latter settings, i.e. spf-interval 5 1 50) tunes the network for optimal reaction for link failures, so routers will immediately start to re-route, with the risk of a subsequent SPF required if the failure was a node failure and additional LSP updates from other nodes are required to judge this. Hence a little more conservative setting uses 50msec initial wait, allowing more LSP updates to come in before the new SPF is calculated.. With LFA-FRR, core failures can be handled differently, so a little less aggressive initial-wait makes a lot of sense in this case.. Either way: even without LFA-FRR, difference between 1 and 50 msec is marginal and not noticeable in practice, so why bother much __ oli ___ 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] Is there a cisco-equivalent of "loop n"(JunOS) as applicable to local-as
Randy, >JunOs "no-prepend-global-as" is the Cisco equivalent of replace-as >JunOS "private" is the Cisco equivalent of no-prepend >JunOS "alias" is the Cisco equivalent of Dual-AS >JunOS "loop n"; Cisco equivalent ??? I think neighbor foo allowas-in is the cmd you’re looking for.. >My google-fu is failing me here. > >Example: > >RTR1 and RTR2 in AS64512 are iBGP peers and peer with RTR3 @ AS64514 using > local-as 64513 > >In the absence of no-prepend in local-as config on RTR1 and RTR2, updates > from RTR3 to RTR1 and 2 would have AS 64513 prepended to updates from R3. >R2 and R1 would receive ibgp updates from each other with > AS64513(local-as) in the as_path - How would the Cisco-RTR1&2 handle these > ibgp-updates from each other? well, IOS/IOS-XR only apply the incoming as-path loop check on eBGP updates, so iBGP updates with your own AS would pass this check just fine, as long as RTR3’s make it into your AS (with the help of allowas-in they would, I guess). > >On JunOS the "loop n" in conjunction with local-as allows me to customize > what I accept as applicable to local-as in received updates. Loop 1 would > hide ibgp updates received with local-as in as-path; loop 2 would allow upto > 1 local-as in as-path. Not entirely sure which policy you want to achieve, but the above might give you some tools? oli ___ 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] Connected routes / Static routes advertised to RR's
> Just an update to this - the "match protocol static" didnt fix the problem, > but adding "next-hop-self" to peer policy didI dont know if both were > required (Only had limited time to test)but static routes on the > RR-client > are now working, as the next hop is now the loop of the rr-client. > Thanks to all who replied...and if anyone could confirm if "both" conf > additions > are necessary, or if just "next-hop-self" is, it would be greatly appreciated > (I wont have access to the routers until tomorrow to test to see if they are > both needed) match protocol static on the RR’s NHT route-map will not make a difference, the route towards the NH is visible via OSPF on the RR, not via static. Using next-hop-self on the edge routers is generally considered best-practice, even if you’re not using selective NHT on the RR.. Oli ___ 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] Connected routes / Static routes advertised to RR's
Nick wrote: > CiscoNSP List wrote: > > Static route to that prefix on the RR-client, shows as "no best path" > > as the 79.106 prefix is "inaccessible"? but as above, it is > > accessible and I can ping it? (So the static is not advertised to any > > other RR-clients): > > you'd make it a lot easier for people to see what was going on if you > used rr# and client# for the prompts, as appropriate. > > What does "show ip route xxx.xxx.79.106" look like on the client? In addition, can you please include your RR BGP config? The next-hop is visible via a /30 route. Do you have selective next-hop tracking configured with route-map limit next-hops to /32s or something else which would require next-hops to be /32? oli ___ 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] BGP blackhole community config
On 20/Jun/16 19:41, Jared Mauch wrote: >> Tags are specific to Cisco, you should be using a community instead. >We use tags on Juniper quite successfully. Makes it easy to introduce >static routes into iBGP. >It irks me that Cisco does not support this. > > You can use something like redistribute static against a route-map that > matches the tag and marks your (local) discard community. >Won't work. >You can't have a tag as a match condition in Cisco. It will throw up an >error that the OP shared earlier. this is not entirely correct: BGP routes don’t have a tag in Cisco’s implementation, so you can’t match against a tag when a route-map controls BGP path advertisements. You can use it when redistributing other route sources which do support tags (statics, etc.) into BGP: r1(config)#route-map FOO r1(config-route-map)#match tag 123 r1(config-route-map)#exit this one works: r1(config)#router bgp 65001 r1(config-router)#redistribute static route-map FOO r1(config-router)# this one doesn’t r1(config-router)#neighbor 1.1.1.1 remote-as 65002 r1(config-router)#neighbor 1.1.1.1 route-map FOO out % "FOO" used as BGP outbound route-map, tag match not supported % not supported match will behave as route-map with no match r1(config-router)# ___ 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] Shutdown an interface based on CRC errors
> >On Thu, Feb 11, 2016 at 10:00:16AM +0100, Robert Hass wrote: >> I'm looking for function which can shutdown an interface if CRC error >> threshold will be overdraft. Is any existing command for this in JunOS >>for >> MX and EX platforms ? >> >> If not maybe some OP script ? > >You sort of hit the wrong list, but if someone has good ideas how to solve >this for IOS, I'm all ears :-) > >(Specifically what I'm looking for is something that hooks into IP SLA or >Ethernet OAM/CFM and takes a link out of IGP routing if packet loss >crosses >a certain threshold - we recently had a carrier break their metro network >in interesting ways, leading to 50% packet loss, which was enough to >effectively take the site offline, but IGP stubbornly clung to "I have >seen a keepalive!") something like this could get you started, Gert? 1) Trigger based on SNMP interface error counters. Rate is always calculated per second. Average factor identifies number of data points (one for each poll-interval) will be averaged for calculation of rate. Average factor needs to be a minimum of 2. event manager applet INTERFACE-ERROS trap event snmp oid ifEntry.14.XX get-type exact entry-op ge entry-val 10 entry-type rate average-factor 2 poll-interval 5 action 20.0 syslog msg "disabling Gigxxx due to errors" action 30.0 cli command "enable" action 30.1 cli command "config terminal" action 40.0 cli command "interface Gig XX" action 50.0 cli command "ip ospf cost " action 60.0 cli command "end" and a reverse to reduce the cost back in case error rates falls below a threshold? you can also trigger based on IP-SLA, for example below trigger 2) Trigger based on RTT delay mib: Use RTT delay mib associated with RTR probes to trigger when the delay is too long. rttMonLatestJitterOperRTTSum shows the sum of delays for probes sent during the last interval. By default 10 probes are sent. To trigger on 10ms RTT delay trigger value must be set below 100. event manager applet TEST3-SNMP-RTT-Delay trap event snmp oid rttMonLatestJitterOperRTTSum.1 get-type exact entry-op ge entry-val 90 entry-type value exit-op le exit-val 20 poll-interval 10 [...] for Ethernet OAM/CFM, you could hook EEM into the syslog messages produced by the syslog? You can also parse the syslog string using regexp, check the applet I found somewhere: event manager applet TunnelLost event syslog occurs 1 pattern "OSPF-5-ADJCHG.*on Tunnel.*FULL to DOWN" period 1 action 100 regexp "on (Tunnel[0-9]+) from" "$_syslog_msg" match ifname action 200 if $_regexp_result eq 1 action 210 cli command "show interface $ifname | include Description:" ... trust you get the gist :) oli ___ 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] ASR9000 ABF question
On Thu, Jul 16, 2015 at 10:06:02AM +0300, Hank Nussbacher wrote: RP/0/RSP0/CPU0:GP1#show access-lists ipv4 catch hardware ingress location 0/1/cpu0 Thu Jul 16 10:03:09.876 IDT ipv4 access-list catch 10 permit ipv4 host 111.107.97.111 any (next-hop: addr=128.139.217.4, vrf Is 128.139.217.4 directly adjacent to this router? As far as I understand, this is a requirement for ABF to work. actually not, next-hop in ABF will be looked up and resolved recursively, if needed.. Hank, the issue looks strange.. best have TAC take a look.. oli ___ 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] OSPF per-prefix LFA
On Thu, May 28, 2015 at 04:06:43PM +0300, George Giannousopoulos wrote: As you have probably already noticed, after OSPF timers tuning, the convergence is quite fast even without the LFA.. So why would you bother to configure LFA in the fiirst place? The interesting bits are in the two letters L and F here. Link-state protocol convergence will cause microloops, LFA avoids those (if possible in the topology given). erm, actually there is loop-free AND microloop free.. two different properties. LFA targets the former, by sending packets over a repair path which is loop-free. You can enhance this to also avoid microloops too while the network converges, but they are different things.. Haven't looked at the details lately, though.. oli ___ 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] Vpdn config ?
my vpdn knowledge is a bit rusty, you're definitely missing a Tunnel-Password for authentication with the remote LNS. You don't need a 2nd vpdn-group for this oli From: Olivier CALVANO o.calv...@gmail.commailto:o.calv...@gmail.com Date: Friday, 20 March 2015 08:35 To: Oliver Boehmer oboeh...@cisco.commailto:oboeh...@cisco.com Cc: CiscoNSP List cisconsp_l...@hotmail.commailto:cisconsp_l...@hotmail.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Vpdn config ? Thanks for your answer, Ok vpdn multihop = i have i add: vpdn authen-before-forward do you know if a second vpdn group is necessary ? my radius sent to my router: Sending Access-Accept of id 57 to 172.20.1.1 port 1645 Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = 172.20.2.100 Tunnel-Type:0 = L2TP Message-Authenticator = 0x Service-Type = Outbound-User Tunnel-Assignment-Id:0 = tunnel-lns Tunnel-Client-Auth-Id:0 = LAC-172-20-1-1 Tunnel-Server-Auth-Id:0 = LNS-172-20-1-1 Tunnel-Client-Endpoint:0 = 172.20.1.1 all is correct ? because 172.20.2.100 never receive a L2TP packet from my router 172.20.1.1 LAC-172-20-1-1 and LNS-172-20-1-1 is on the vpdn-group that receiv the session of my suplier with this modification, we have now on my router debug : Mar 20 07:33:12.708: VPDN Received L2TUN socket message xCRQ - Session Incoming Mar 20 07:33:12.712: VPDN uid:85 L2TUN socket session accept requested Mar 20 07:33:12.712: VPDN uid:85 Setting up dataplane for L2-L2, no idb Mar 20 07:33:12.900: VPDN Received L2TUN socket message xCCN - Session Connected Mar 20 07:33:12.900: VPDN uid:85 VPDN session up Mar 20 07:33:13.036: VPDN MGR: Received message, client dialin request Mar 20 07:33:13.036: VPDN uid:85 L2TUN socket session connect requested Mar 20 07:33:13.036: VPDN uid:85 Setting up dataplane for L2-L2, no idb Mar 20 07:33:13.072: %VPDN-6-AUTHENERR: L2TP LNS-172-20-1-1 cannot authenticate for tunnel ; Result 4, Error 0, process challenge failed Mar 20 07:33:13.072: VPDN Received L2TUN socket message CDN - Session Disconnected Mar 20 07:33:13.072: VPDN uid:85 disconnect (L2X) IETF: 9/nas-error Ascend: 48/Security Fail Mar 20 07:33:13.072: VPDN uid:85 vpdn shutdown session, result=101, error=0, vendor_err=0, syslog_error_code=3, syslog_key_type=0 Mar 20 07:33:13.076: VPDN CALL [uid:85]: Received client message client connect fail Mar 20 07:33:13.076: VPDN uid:85 disconnect (AAA) IETF: 9/nas-error Ascend: 48/Security Fail Mar 20 07:33:13.076: VPDN uid:85 vpdn shutdown session, result=101, error=0, vendor_err=0, syslog_error_code=3, syslog_key_type=0 Mar 20 07:33:13.080: VPDN uid:85 VPDN/AAA: accounting stop sent VPDN-6-AUTHENERR: L2TP LNS-172-20-1-1 cannot authenticate for tunnel ? regards Olivier 2015-03-20 8:01 GMT+01:00 Oliver Boehmer (oboehmer) oboeh...@cisco.commailto:oboeh...@cisco.com: You might need vpdn multihop vpdn authen-before-forward the first cmd will enable forwarding of sessions to another LNS, and the 2nd will allow this forwarding to be done on a per-user (as opposed to per-domain/realm) basis oli -Original Message- From: Olivier CALVANO o.calv...@gmail.commailto:o.calv...@gmail.com Date: Friday, 20 March 2015 06:39 To: CiscoNSP List cisconsp_l...@hotmail.commailto:cisconsp_l...@hotmail.com Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Vpdn config ? Yes based on realm but based on radius attributs , not a physical config on the router. The tunnel destination is sent by the radius of my customer Le vendredi 20 mars 2015, CiscoNSP List cisconsp_l...@hotmail.commailto:cisconsp_l...@hotmail.com a écrit : You want to do VPDN Multihop based on a specific domain? (i.e. forward connection requests for a specific realm to an alternate LNS (So create an L2TP tunnel)) If so, I set one of these up a couple of years agoill dig up the working conf if that's what you are trying to do. Date: Fri, 20 Mar 2015 04:29:43 +0100 From: o.calv...@gmail.commailto:o.calv...@gmail.com javascript:_e(%7B%7D,'cvml','o.calv...@gmail.commailto:o.calv...@gmail.com'); To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net javascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net'); Subject: Re: [c-nsp] Vpdn config ? i have one vpdn-group only: vpdn-group UserLNS accept-dialin protocol l2tp virtual-template 1 terminate-from hostname LAC-172-20-1-1 local name LNS-172-20-1-1 lcp renegotiation always no l2tp tunnel authentication l2tp tunnel receive-window 500 l2tp tunnel retransmit retries 7 l2tp tunnel retransmit timeout min 2 l2tp tunnel retransmit timeout max 7 interface Virtual-Template1 description DSL User mtu
Re: [c-nsp] Vpdn config ?
If you don't want tunnel authentication, you would need to include Cisco-avpair = vpdn:l2tp-tunnel-authen=no in the radius response.. not sure if there is an IETF attribute for this.. From: Olivier CALVANO o.calv...@gmail.commailto:o.calv...@gmail.com Date: Friday, 20 March 2015 09:05 To: Oliver Boehmer oboeh...@cisco.commailto:oboeh...@cisco.com Cc: CiscoNSP List cisconsp_l...@hotmail.commailto:cisconsp_l...@hotmail.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: Vpdn config ? A tunnel-password is obligatory ? Sent by the radius ? Because with my suplier we dont have tunnel-password I cant test now but it's a track I'll watch Regards Olivier Le vendredi 20 mars 2015, Oliver Boehmer (oboehmer) oboeh...@cisco.commailto:oboeh...@cisco.com a écrit : my vpdn knowledge is a bit rusty, you're definitely missing a Tunnel-Password for authentication with the remote LNS. You don't need a 2nd vpdn-group for this oli From: Olivier CALVANO o.calv...@gmail.comjavascript:_e(%7B%7D,'cvml','o.calv...@gmail.com'); Date: Friday, 20 March 2015 08:35 To: Oliver Boehmer oboeh...@cisco.comjavascript:_e(%7B%7D,'cvml','oboeh...@cisco.com'); Cc: CiscoNSP List cisconsp_l...@hotmail.comjavascript:_e(%7B%7D,'cvml','cisconsp_l...@hotmail.com');, cisco-nsp@puck.nether.netjavascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.net'); cisco-nsp@puck.nether.netjavascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.net'); Subject: Re: [c-nsp] Vpdn config ? Thanks for your answer, Ok vpdn multihop = i have i add: vpdn authen-before-forward do you know if a second vpdn group is necessary ? my radius sent to my router: Sending Access-Accept of id 57 to 172.20.1.1 port 1645 Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = 172.20.2.100 Tunnel-Type:0 = L2TP Message-Authenticator = 0x Service-Type = Outbound-User Tunnel-Assignment-Id:0 = tunnel-lns Tunnel-Client-Auth-Id:0 = LAC-172-20-1-1 Tunnel-Server-Auth-Id:0 = LNS-172-20-1-1 Tunnel-Client-Endpoint:0 = 172.20.1.1 all is correct ? because 172.20.2.100 never receive a L2TP packet from my router 172.20.1.1 LAC-172-20-1-1 and LNS-172-20-1-1 is on the vpdn-group that receiv the session of my suplier with this modification, we have now on my router debug : Mar 20 07:33:12.708: VPDN Received L2TUN socket message xCRQ - Session Incoming Mar 20 07:33:12.712: VPDN uid:85 L2TUN socket session accept requested Mar 20 07:33:12.712: VPDN uid:85 Setting up dataplane for L2-L2, no idb Mar 20 07:33:12.900: VPDN Received L2TUN socket message xCCN - Session Connected Mar 20 07:33:12.900: VPDN uid:85 VPDN session up Mar 20 07:33:13.036: VPDN MGR: Received message, client dialin request Mar 20 07:33:13.036: VPDN uid:85 L2TUN socket session connect requested Mar 20 07:33:13.036: VPDN uid:85 Setting up dataplane for L2-L2, no idb Mar 20 07:33:13.072: %VPDN-6-AUTHENERR: L2TP LNS-172-20-1-1 cannot authenticate for tunnel ; Result 4, Error 0, process challenge failed Mar 20 07:33:13.072: VPDN Received L2TUN socket message CDN - Session Disconnected Mar 20 07:33:13.072: VPDN uid:85 disconnect (L2X) IETF: 9/nas-error Ascend: 48/Security Fail Mar 20 07:33:13.072: VPDN uid:85 vpdn shutdown session, result=101, error=0, vendor_err=0, syslog_error_code=3, syslog_key_type=0 Mar 20 07:33:13.076: VPDN CALL [uid:85]: Received client message client connect fail Mar 20 07:33:13.076: VPDN uid:85 disconnect (AAA) IETF: 9/nas-error Ascend: 48/Security Fail Mar 20 07:33:13.076: VPDN uid:85 vpdn shutdown session, result=101, error=0, vendor_err=0, syslog_error_code=3, syslog_key_type=0 Mar 20 07:33:13.080: VPDN uid:85 VPDN/AAA: accounting stop sent VPDN-6-AUTHENERR: L2TP LNS-172-20-1-1 cannot authenticate for tunnel ? regards Olivier 2015-03-20 8:01 GMT+01:00 Oliver Boehmer (oboehmer) oboeh...@cisco.comjavascript:_e(%7B%7D,'cvml','oboeh...@cisco.com');: You might need vpdn multihop vpdn authen-before-forward the first cmd will enable forwarding of sessions to another LNS, and the 2nd will allow this forwarding to be done on a per-user (as opposed to per-domain/realm) basis oli -Original Message- From: Olivier CALVANO o.calv...@gmail.comjavascript:_e(%7B%7D,'cvml','o.calv...@gmail.com'); Date: Friday, 20 March 2015 06:39 To: CiscoNSP List cisconsp_l...@hotmail.comjavascript:_e(%7B%7D,'cvml','cisconsp_l...@hotmail.com'); Cc: cisco-nsp@puck.nether.netjavascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.net'); cisco-nsp@puck.nether.netjavascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.net'); Subject: Re: [c-nsp] Vpdn config ? Yes based on realm but based on radius attributs , not a physical config on the router. The tunnel destination is sent by the radius of my customer Le vendredi 20 mars 2015, CiscoNSP List cisconsp_l...@hotmail.comjavascript:_e(%7B%7D,'cvml
Re: [c-nsp] Vpdn config ?
You might need vpdn multihop vpdn authen-before-forward the first cmd will enable forwarding of sessions to another LNS, and the 2nd will allow this forwarding to be done on a per-user (as opposed to per-domain/realm) basis oli -Original Message- From: Olivier CALVANO o.calv...@gmail.com Date: Friday, 20 March 2015 06:39 To: CiscoNSP List cisconsp_l...@hotmail.com Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Vpdn config ? Yes based on realm but based on radius attributs , not a physical config on the router. The tunnel destination is sent by the radius of my customer Le vendredi 20 mars 2015, CiscoNSP List cisconsp_l...@hotmail.com a écrit : You want to do VPDN Multihop based on a specific domain? (i.e. forward connection requests for a specific realm to an alternate LNS (So create an L2TP tunnel)) If so, I set one of these up a couple of years agoill dig up the working conf if that's what you are trying to do. Date: Fri, 20 Mar 2015 04:29:43 +0100 From: o.calv...@gmail.com javascript:_e(%7B%7D,'cvml','o.calv...@gmail.com'); To: cisco-nsp@puck.nether.net javascript:_e(%7B%7D,'cvml','cisco-nsp@puck.nether.net'); Subject: Re: [c-nsp] Vpdn config ? i have one vpdn-group only: vpdn-group UserLNS accept-dialin protocol l2tp virtual-template 1 terminate-from hostname LAC-172-20-1-1 local name LNS-172-20-1-1 lcp renegotiation always no l2tp tunnel authentication l2tp tunnel receive-window 500 l2tp tunnel retransmit retries 7 l2tp tunnel retransmit timeout min 2 l2tp tunnel retransmit timeout max 7 interface Virtual-Template1 description DSL User mtu 1460 ip unnumbered Loopback100 ip tcp adjust-mss 1420 no logging event link-status no peer default ip address keepalive 20 ppp mtu adaptive ppp authentication chap ppp-radius ppp multilink It's linked with the loopback100 but i put: Tunnel-Client-Endpoint:0 = 172.20.1.1 172.20.1.1 is not the IP of Loopback100, it's a problems ? because the first tunnel (my supplier to my router) work, this vpdn/virtual-template is good i think's but for the second tunnel, my router to my customer, it should not be a second vpdn/virtual-template in out ? thanks for your help 2015-03-19 10:37 GMT+01:00 Olivier CALVANO o.calv...@gmail.com javascript:_e(%7B%7D,'cvml','o.calv...@gmail.com');: Hi i am search a vpdn config sample for my cisco 7301. I want forward a ppp connexion to another router. My radius sent to my router a Tunnel-End-Point but he don't forward (i see the connection in sh users) thanks for your help olivier ___ cisco-nsp mailing list cisco-nsp@puck.nether.net javascript:_e(%7B%7D,'cvml','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/ ___ 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] Redist BGP routes to other PE's (In same VRF)
Hi Everyone, I have a vrf (TEST), configured on 2 PE's...both learn each others connected+static routes (redist connnected, redist static), so that portion is working fine...but I also have leaked the default route from PE_A (That we receive from an upstream provider), into the vrf TESTon PE_A, I can see the detault route in the VRF TEST, and also GRT, and I can get to the Internet from an IP within the VRFI have default-information originate on PE_A for vrf TEST, but the default route is not being propagated to PE_B...the default route is seen as type BGP when I issue sh ip route vr TEST/sh ip route vrf test 0.0.0.0any suggestions on what is needed to redist this BGP route to the other PE in the VRF? i.e. under address family vrf TEST, redistribute BGP xxx (with a route map to ensure only the default is distributed to the other PE?) A PE which imports a route into a VRF (and importing from global is no exception) will not advertise this route via iBGP to other PEs. So you would need to configure the same import on PE_B too.. oli ___ 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] Can one CSC-CE be parented to 2 CSC-PE
Hi, We are trying to parent one CSC-CE to two CSC-PE. The ISP is having MPLS and RR and we are not able to succeed. Is this technically possible. yes, it is. so it works if you single-home the CSC-CE to the ISP? requires much more info about the setup/design to troubleshoot further. oli ___ 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] IOS-XR and PBR
I am looking to setup some policy based routing on an IOS-XR router. From what I understand, XR does not have PBR, but ABF. When looking at how ABF works, I don¹t see how to set a next hop route (only next hop per TCP port). well, you can direct any traffic matching an ACE (be it layer 3 or 4) to a chosen next-hop. My question then would be, how does one accomplish this on XR? What I need to do is allow a particular IP block to only have access to one of our backbone carriers and not the others. We have their /24 only announced out the one carrier, but for outbound traffic, I want to make sure their traffic remains on that carrier but also have access to our local routes (all our local customers and local networks). Is this something that can be done with ABF Yes, it can be done, but possibly a bit more difficult: ipv4 access-list ABF permit CUST/24 your-own-netblocks permit CUST/24 0.0.0.0/0 next-hop your-upstream-provider not sure how your topology looks and where you would need to apply this forwarding rule, but the next-hop can be directly connected or resolve via some form of tunnel (including LDP/LSP). oli ___ 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] IOS-XR and PBR
Since we have no default routes and all backbone links are full BGP minus default route, I am going to assume that the second permit statement won't work here. Would this just get specified as any since the first entry would be matched for local netblocks and sorry, 0.0.0.0/0 should be any.. so the first line matches traffic to your networks (and it just passes through normally and will be forwarded according to your RIB/FIB), and the 2nd matches traffic from this customer block to anything else, which then will be ABF'ed to your upstream. it would not go further in the ACL? it actually would, so I missed a permit ipv4 any any catch-all at the end of the ACL to ensure traffic from other sources is forwarded normally.. it is a regular ACL, the ABF directives are just inserted into it. Need more coffee.. These special case customers all are fed from a single 6509 to the border router that contains their one carrier of choice, but that border router contains several backbone links and each border router also having links to each other. I suspect that for simplifying this, we can match against traffic on the link coming from that 6509 to the border router. exactly, that sounds straight-forward, just apply this inbound and you're set.. oli Thanks for the pointers. -Lee On Wed, Sep 10, 2014 at 11:09 PM, Oliver Boehmer (oboehmer) oboeh...@cisco.com wrote: I am looking to setup some policy based routing on an IOS-XR router. From what I understand, XR does not have PBR, but ABF. When looking at how ABF works, I don¹t see how to set a next hop route (only next hop per TCP port). well, you can direct any traffic matching an ACE (be it layer 3 or 4) to a chosen next-hop. My question then would be, how does one accomplish this on XR? What I need to do is allow a particular IP block to only have access to one of our backbone carriers and not the others. We have their /24 only announced out the one carrier, but for outbound traffic, I want to make sure their traffic remains on that carrier but also have access to our local routes (all our local customers and local networks). Is this something that can be done with ABF Yes, it can be done, but possibly a bit more difficult: ipv4 access-list ABF permit CUST/24 your-own-netblocks permit CUST/24 0.0.0.0/0 http://0.0.0.0/0 next-hop your-upstream-provider not sure how your topology looks and where you would need to apply this forwarding rule, but the next-hop can be directly connected or resolve via some form of tunnel (including LDP/LSP). oli ___ 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] IOS-XR and PBR
Looks like I may not have this feature as these are 12410XR chassis. Here is what I have in our lab environment. true, unfortunately ABF is not supported on the XR12000 platform. it works on ASR9k and CRS.. oli ___ 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] IOS: catch 22 when enabling new bgp neighbors
a new BGP session, before I can shutdown the neighbor or apply a specific peer-group/session-template/policy-template, I need to configure the remote-as, so the first command in the address-family is: neighbor 2001::123 remote-as 65005 Now, if I don't specify the policies right away, or shutdown the session right away (or the ssh terminal slows down for whatever reason), IOS will establish the BGP session as-is (without any policies), until I manage to configure the rest. There is an open delay for external BGP neighbours of 30 sec (10 sec for iBGP), jittered to +- 50%.. so at least for iBGP you should have more than a few seconds to configure shut on an eBGP session, even over a slow connection.. if you want to be extra sure, just do conf net or the likes.. oli ___ 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] IOS: catch 22 when enabling new bgp neighbors
[neighbor 192.0.2.100 remote-as 64511 shutdown] Wow, you can do that? I feel really really dumb now... so do I ;-) oli ___ 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] BGP vs OSPF (CE - PE)
Hi Everyone, We typically use OSPF (CE/PE) so customer can advertise routes into their VRF - We have issues with failover (When customer site has 2 links) but the links go to different PEs of ours (We only have agg's from carriers on certain PE's).. eg. Customer(vrf) has a site(foo) connected to PE A + B (PE B is failover link) Same customer has another site(bar) connected to PE B. Traffic from site bar to foo will go via PE B, which is not what we want...we have manipulated this to work via longer subnets (i.e. failover link advertising a /23 instead of a /24), but this isnt always feasible. Would BGP(Instead of OSFP) help in this situation...i.e. Can we manipulate how the routes are advertised(PE A/B) within the vrf more easily if the CE advertises via BGP vs OSPF? Or any other suggestions? OSPF sham links have been introduced to help in this situation, but BGP is certainly easier as it doesn't need those and you can manipulate the policy using normal BGP attributes.. oli ___ 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] ISIS IOS and IOS XR
-Original Message- From: M K gunner_...@live.com Date: Tuesday, 3 June 2014 11:03 To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Subject: [c-nsp] ISIS IOS and IOS XR Hi all I am having issue establishing ISIS between IOS and IOS XR IOS R1#sh run int lo0 | inc ipv6 ipv6 address 2001::1/128 ipv6 router isis 1 R1#sh run int fas1/0 | inc ipv6 ipv6 address 2001:192:102::1/64 ipv6 router isis 1 router isis 1 net 49.0001...0001.00 is-type level-2-only metric-style wide IOS XR RP/0/0/CPU0:XR1#sh run router isis Tue Jun 3 12:00:23.223 UTC router isis 1 is-type level-2-only net 49.0001...0010.00 interface Loopback0 address-family ipv4 unicast address-family ipv6 unicast interface GigabitEthernet0/0/0/0 address-family ipv4 unicast address-family ipv6 unicast I tried without the metric-style wide on the IOS and the same , as well , I have configured on the IOS address-family ipv6 unicast under the router isis 1 process and the same , what am missing? Please enable router isis 1 metric-style wide address-family ipv6 unicast multi-topology IOS-XR defaults to multi-topoloy when multiple AFs are used, but you need to enable it in IOS.. oli ___ 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] Cisco IOS XR Redistribution
route-policy CONNECTED if source in (192.168.200.0/24, 192.168.201.0/24) then pass endif end-policy RP/0/0/CPU0:XR2(config)#router ospf 1 RP/0/0/CPU0:XR2(config-ospf)#redistribute connected route-policy CONNECTED Am getting the below error router ospf 1 redistribute connected route-policy CONNECTED !!% Could not find entry in list: Policy [CONNECTED] uses the 'source' attribute. There is no 'source' attribute at the ospf redistribution attach point. I tried it using a prefix-set but the same issue you need to match destination, I.e. if destination in (192.168.200.0/24, 192.168.201.0/24) then pass endif oli ___ 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] BGP Signalled VPLS
On Monday, April 28, 2014 07:25:27 PM Aaron wrote: p.s. does anyone know if the bgp graceful-restart is really necessary ? if so, why? In my shiny new deployment, I'm considering turning off GR if I do NSR. They are mutually exclusive. well, as I mentioned in an earlier thread: GR still serves as a fallback mechanism to NSR (in case something goes wrong and the standby RP looses NSR sync), and it will help non-NSR-neighbours to fall over gracefully. If all the neighbours run NSR, GR provides less of a value, only for fallback.. I've been a die-hard GR customer for a while now, but after reviewing infrastructure improvements to NSR, I think I'm ready to take the plunge. good to hear, NSR on XR is quite widely deployed these days.. oli ___ 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] Cisco to support flow spec?
On Mar 21, 2013, at 4:30 PM, Justin M. Streiner strei...@cluebyfour.org wrote: The last I heard (in the past month) was that this was a 2014 roadmap item. I don't if it's EC'd for a specific version yet, nor do I know what platforms will be supported. My guess would be ASR9K/1K, Nexus 7K, maybe the CRS, 6500/Sup2T and 7600. That's better than the We don't support BGP Flowspec answer I got a year or so ago. When I explained that Cisco co-authored RFC 5575, they seemed to soften their stance a bit ;) To revive an old threadŠ Has anyone heard anything new on this topic in the past year? It now being the aforementioned 2014 and all? will ship in 5.2.0 soon and XE 3.14 later this year.. oli ___ 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] Cisco to support flow spec?
On Sun, 4 May 2014, Oliver Boehmer (oboehmer) wrote: To revive an old threadŠ Has anyone heard anything new on this topic in the past year? It now being the aforementioned 2014 and all? will ship in 5.2.0 soon and XE 3.14 later this year.. Any word on support in NX-OS? 7.3, last I heard.. Also, is this RFC 5575-compliant flowspec? yes, with some recent enhancements to the specs (v6 support, relaxed origin check, extra redirect options, and a few more) oli ___ 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] Hierarchical FIB on Cisco 7600
Thank you all; so let me just see if I got this right. If we're not loadbalancing with IGP (instead there's primary/backup uplink) on edge, and not using H.FIB (with cef table output-chain build favor convergence-speed) and we're running full BGP table on edge routers, anyone with experience on how would flat FIB affect convergence without PIC Core on 7600? In other words what would be real life effect of rewriting couple of hundred thousand entries to point to new output interface in terms of convergence? I don't have a recent performance study, but I saw a 7600 w/ 200k IPv4 prefixes taking ~17 seconds to rewrite all prefixes, where hierarchical FIB cut this down to 1 sec. If you don't mind, could you explain part with VPNv4 requires recirc ? I'm not sure what does that mean in relation with PIC Core? it means it'll cut the pps performance in half for vpn traffic with H.FIB. And if I understand, since we're already installing in CEF 'repair' path in PIC Edge scenario, then H.FIB is not really required? It is. We can't leverage the repair path unless we have a hierarchical FIB structure. oli ___ 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] EIGRP Authentication on IOS XR
can you add send-lifetime .. to the key? It might not be active without it.. key chain KEY key 1 key-string password cisco cryptographic-algorithm md5 send-lifetime 01:01:00 january 01 2014 infinite -Original Message- From: M K gunner_...@live.com Date: Wednesday, 23 April 2014 16:49 To: Pete Lumbis alum...@gmail.com Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Subject: Re: [c-nsp] EIGRP Authentication on IOS XR No , the only option under the interface is authentication keychain command The cryptographic-algorithm MD5 command is under the key chain command , I have tried it but did not work for me ! Date: Tue, 22 Apr 2014 13:16:14 -0400 Subject: Re: [c-nsp] EIGRP Authentication on IOS XR From: alum...@gmail.com To: gunner_...@live.com CC: cisco-nsp@puck.nether.net I think the next line after authentication keychain is cryptographic-algorithm MD5 On Tue, Apr 22, 2014 at 10:55 AM, M K gunner_...@live.com wrote: Hi all I am facing an issue when configuring EIGRP authentication between IOS and IOS XR R1#sh run | sec key chain key chain KEY key 1 key-string cisco R1#sh run int f0/0 | inc authen ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 KEY RP/0/0/CPU0:XR1#sh run key chain Tue Apr 22 17:54:14.480 UTC key chain KEY key 1 key-string password cisco router eigrp EIGRP_PROCESS address-family ipv4 autonomous-system 1 interface Loopback0 ! interface GigabitEthernet0/0/0/0 authentication keychain KEY Under the interface GigabitEthernet0/0/0/0 located under the EIGRP process , I did not find an option for choosing MD5 Any ideas? Thanks ___ 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/ ___ 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] Bundle member issue
HI, On Thu, Apr 10, 2014 at 03:11:38PM -0500, Alejandro Aristizabal wrote: How can I make if this happen again, the interface Gi0/0/0/19 goes down ? UDLD, or plain GigE autonegotiation. or just plain LACP, which will take the link out of the bundle? oli ___ 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] ISIS Distance question
Hi JC, The real life problem is A and B are PE routers and C is the RR. So I do not have MPLS on the interfaces towards C from A B. So when the A-B link fails, it will break the label switched path between them. A and B have CsC links which should then be preferred.. If you are using separate Control-Plane (RRs that are not part of the MPLS/data-plane) you may set the overload bit on your RRs via the router isis cmd: set-overload-bit. This will assign maximum ISIS metric to all links advertised by the RR -this will assure that RR will never end up on the forwarding path between any two PEs. indeed overload bit would be the best approach.. and to be exact: an IS with OL-bit set will never be considered as transit while building the SPF, no matter how high or low the link metrics are.. OSPF, short of an OL-bit concept, will use max metrics to achieve the same.. oli ___ 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] interesting ASR 9k bgp multipath issue
so, I have some internally anycasted prefixes (DNS resolvers) as well as bgp maximum paths set to allow both ibgp and ebgp multipath. Oddly, as you can see below the multipath appears to think two paths are identical even when they have different IGP metrics (path #1 and path #2), any idea if this is a bug or how to fix it?Obviously if the IGP cost is the same it should load share, but if not it really should not be doing what is shown below since the paths are not equal. John, what exactly did you configure in your BGP address-family? It looks like you enabled maximum-paths eibgp n, which also considers paths with different metrics as multipath candidates. oli ___ 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] interesting ASR 9k bgp multipath issue
Yes, I did, but my point is that behavior is not the same or at least appears not to be the same on IOS, I want ibgp multipath but only for things with matching IGP metrics, is there a way to tweak that. IOS also behaves the same if configured the same (with maximum-paths eigbp).. as Jared pointed out, you want to enable maximum-paths ibgp n (and possibly maximum-paths ebgp n if you also want to load-share eBGP peers). the configuration of maximum-paths eibgp n is not a shortcut for and hence is different to maximum-paths ibgp n maximum-paths ebgp n oli -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Monday, March 31, 2014 11:26 AM To: John van Oppen; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] interesting ASR 9k bgp multipath issue so, I have some internally anycasted prefixes (DNS resolvers) as well as bgp maximum paths set to allow both ibgp and ebgp multipath. Oddly, as you can see below the multipath appears to think two paths are identical even when they have different IGP metrics (path #1 and path #2), any idea if this is a bug or how to fix it?Obviously if the IGP cost is the same it should load share, but if not it really should not be doing what is shown below since the paths are not equal. John, what exactly did you configure in your BGP address-family? It looks like you enabled maximum-paths eibgp n, which also considers paths with different metrics as multipath candidates. oli ___ 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] LDP based CSC VPN - ASR9k/IOS-XR 4.3.4
CsC with LDP was just released in 5.1.1 (http://tools.cisco.com/squish/AEe16) oli -Original Message- From: Phil Bedard phil...@gmail.com Date: Monday, 10 March 2014 18:34 To: Arun Kumar narain.a...@gmail.com, cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LDP based CSC VPN - ASR9k/IOS-XR 4.3.4 I'm not sure 4.3.4 supports it, I thought I read it came in a later release? I can't seem to find it in the release notes though... Phil On 3/10/14, 8:43 AM, Arun Kumar narain.a...@gmail.com wrote: Hi All, I am trying to configure CSC MPLS VPN on IOS-XR 4.3.4 on ASR 9K as PE. Currently the configuration is on NPE-G2 and NPE-G1 as PE routers. LDP is configured between PE and CE for label exchange and OSPF is the protocol between PE and CE. When I try to configure LDP between ASR9K and CPE, I am not getting LDP as the option between PE and CE, I am not getting any option of specifying LDP under the VRF. Even the IOS-XR MPLS config guide only talks about BGP based label exchange between PE and CE on IOS-XR. I would like to confirm, can LDP be configured under VRF in ASR9K as PE or BGP is the only option available? thanks in advance Arun ___ 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/ ___ 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] Event Manager Script
can you just remove the action 2.0 reload from the script for the test so the router just spits out the syslog and then send the logs? I noticed that the maximum delay down value accepted by the parser is 180 (3 minutes), maybe it didn't accept the command when you pasted it? I just tested this (with 60 sec delay), and it seems to work fine (debug track enabled): router(config)# Mar 5 09:53:14.230: Track: 99 Down change delayed for 60 secs Mar 5 09:54:14.231: Track: 99 Down change delay expired Mar 5 09:54:14.231: Track: 99 Change #3 ip sla 99, reachability Up-Down Mar 5 09:54:14.231: %TRACKING-5-STATE: 99 ip sla 99 reachability Up-Down Mar 5 09:54:14.239: %HA_EM-6-LOG: reload-if-down: Reloading the router due to unreachability and as EEM only triggers on up-down transition, it only takes action when the probe was up at least once. so this is good.. oli From: M K gunner_...@live.commailto:gunner_...@live.com Date: Wednesday, 5 March 2014 09:26 To: Oliver Boehmer oboeh...@cisco.commailto:oboeh...@cisco.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Event Manager Script Hi , thanks and sorry for the late reply I am facing some issues with the script , when the IP SLA is down , the router did not wait for the 5 minutes , it reloaded directly From: oboeh...@cisco.commailto:oboeh...@cisco.com To: gunner_...@live.commailto:gunner_...@live.com; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Event Manager Script Date: Sun, 2 Mar 2014 12:33:34 + Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] Event Manager Script
Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] Questions regarding 6PE and route aggregation
hi. note: I haven;t touched 6PE in a while, so I might not be 100% accurate: I’ve been trying to evaluate 6PE as a transition mechanism lately and I’ve stumbled upon something I didn’t initially expert. My understanding of 6PE is as follows ( and feel free to correct me if I’m wrong ☺ ) : PE-A and PE-B peer over IPv4, they exchange routes and labels. Packets transit the core over ipv4 and have 2 labels; outer label describes the LSP towards the remote PE while the inner label describes the actual IPv6 next hop ( “CE” or whatever you want to call it ). Label allocation is per-prefix ( unless you switch to 6VPE, where you can actually change it, with all the consequences that follow ). So, I’ve been thinking, what if I don’t want to send the full table to some PEs, but only internal routes and a default route ? Internal routes obviously shouldn’t pose an issue, but aggregating everything to the default is somewhat trickier. So, I fired up my lab, got an ebgp session with an upstream and…here’s what happened: Scenario A, get a default route from an upstream and advertise it downstream while suppressing all other external routes: Everything works fine. Would it work fine with 1 upstream though, or would I get suboptimal routing, as the PE with the full table would just perform a lookup on the inner label ( which would correlate to whatever single default route was preferred from upstreams ) ? yes. you can check this by looking at the LFIB entry of the label BGP assigned to the ::/0, it should point straight out to the egress interface. Scenario B, no default route from upstreams. Just generating one towards downstreams with default-information originate: Control plane looks ok , data plane just fails! how does the RIB/FIB/LFIB look like? How exactly do you generate the default? via neighbor default-information-originate? Scenario C, same as scenario B apart from the addition of a static default to Null0 on the PE originating the default route: Surprisingly, it works. Is it supposed to work though ? If so, should I assume it’s doing 2 lookups ( one of the label and one for the actual prefix ) with all the performance implication this carries ? My guess is that the PE originates an aggregate label, which tells the PE to do another lookup. This is just a guess.. Also, any advise on how you tackled similar issues would be greatly appreciated. Assuming scenario C is a valid design, it feels kinda wasteful. why? BTW: There is a thread on https://supportforums.cisco.com/thread/2006006 about this.. oli ___ 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] OSPF: inconsistent SPF/LSA throttle timers
we are currently running a small OSPF network with about 50+ boxes using default IOS timers. We would like to tune LSA/SPF throttle timers. Now, because some of the boxes have a decent CPU (ASR1000, 6500, etc) running more important traffic, and others have a small cpu, like ME3400 layer 3 switches, we wanted to tune the OSPF timers on those important boxes specifically. SPF + RIB update on the ME3400 amounts for up to 250 ms, which is why we prefer to leave them as-is, or at least, roll those changes out gradually. A general remark: There are two kinds of timers: Those which control LSA flooding and reception, and those which control the SPF throttling. You can use different SPF-throttle timers across the domain, at the danger of running into transient loops in case intermediate nodes with lower timers have not completed their SPF (you mention this later). So if you have some nodes kicking SPF off after 50 msec, and others wait 5 seconds, your end-to-end convergence might not have improved at all, but you are aware of this. For LSA origination/lsa-throttle, you have a dependency on the min-lsa-arrival timer, which is, by default (and by RFC) 1 second. If you tune your lsa-throttle in such a way that a node might flood two instances of the same LSA within one second, other nodes which still run with the min-lsa-arrival of 1 second will discard the latter instances, which is not good as it requires retransmissions and impacts end-to-end convergence. as for the default settings: you do want to tune down lsa-throttle on all devices, by default IOS waits 5 second before sending another LSA, which could be bad for flapping links.. and at least oder IOS releases waited ~5 second before starting SPF, have not followed any changes here lately.. Here comes the question: a concern was raised, that if we are running an OSPF area with different LSA/SPF timers on the boxes, we may hit a race condition where a box discards an incoming LSA, and the OSPF database only recovers after the LSA is refreshed (after the 30 or 50 minutes) or it doesn't recover at all when using flood-reduction [1]. Yes. So the first thing you want to do is to make sure that all devices in the flooding domain have timers lsa arrival with a low value like 20 msec configured. Then you can tune down the hold-interval value of timers throttle lsa all down. a common deployment is timers throttle lsa all 0 20 1000 timers lsa arrival 20 timers pacing flood 15 If you have devices which don't allow tuning the min-lsa-arrival timer, you need to use a higher hold-down (I.e. timers throttle lsa all 0 1000 1000). As for SPF throttle, a common FC tuning is timers throttle spf 50 100 5000... You don't want to configure flood reduction, I haven't seen this enabled anywhere ever.. Personally, I don't think thats the case. Also, none of the documentation I read suggests that. It would also mean that we cannot change the throttle timers in a live network gradually, but need to shutdown the entire OSPF network to adjust the timers. I can't believe thats the case. No, that's a myth.. you might want to configure timers lsa arrival on all boxes before you start with lsa-throttle. I do agree that it would be better to have a fully consistent configuration, and we will try to achieve that at one point, but until then, does anyone run a production network with inconsistent LSA/SPF throttle timers? it's done, especially in a multi-vendor environment where not every device supports SPF/LSA throttle (as do very old Cisco devices).. I have my doubts that big heterogeneous networks really use consistent SPF/LSA timers across all boxes. mostly consistent, I would say. not every implementation supports the same throttling algorithm, but the initial wait timers are sync'ed.. oli ___ 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] asr9000 policy-map on bundle interface
On Monday, February 17, 2014 03:24:04 PM Cydon Satyr wrote: Should a policy-map with priority/bandwidth/queue parameters be applied on a bundle interface or individual physical interfaces? With IOS XR, QoS policies are applied on the bundle interface, not the member links. true, however they are enforced on the physical member links (check out, for example, http://tools.cisco.com/squish/e8189). This gets tricky when you want to police/shape some traffic across multiple members to a fixed amount as there is no shared policy instance across physical ports. oli ___ 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] Multi-VRF on MPLS-VPN
Hello team, I running an MPLS VPN network over ASR1002 Cisco routers and i have a request from a client to offer multi-VRF. Is it possible to run the multi-VRF without affecting the current MPLS network and setup. not sure what you mean exactly, but you can just run two separate L3 interfaces (like vlan subinterfaces) to the client's CE, and put each of it in a different VRF/VPN. If you also manage the CE, you can just put the new/2nd (sub)interface in a VRF (vrf-lite) and also offer separate (sub)interfaces to the customer. Doesn't require any changes on the overall MPLS-VPN architecture per se.. oli ___ 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] Remote LFA on IOS XR -does it require Explicit Null MPLS Labels?
Hi Folks, Is anybody running Remote LFA on IOS XR please? Does it require explicit null labels to be enabled network wide please? generally yes, reason is that some platforms/versions (don't have the details ready just now) can't rLFA-protect a primary path which has no label (due to imp-null). oli ___ 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] IOS-XR ACL-Based Forwarding (ABF)
Are object-gropus not supported with ABF? no, unfortunately not yet. It's on the roadmap for a future release.. oli ___ 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] Redundancy options for Dual Home Devices using EoMPLS or VPLS
Daniel, I'm trying to find any design guide, white paper, Cisco live presentation or other relevant documents that describe different redundancy scenarios for a network like this: http://imgur.com/mBqpqRf The design is not final so if you have any pointers on that as well I would appreciate it. you can check out the session BRKSPG-2207 (Redundancy Mechanisms for Carrier Ethernet and Layer 2 VPN Services) on ciscolive.com which provides a good overview of the approaches for CE/L2VPN redundancy. L3 is straight-forward, as you said. make sure you use unique RDs for your L3VPN VRFs, and check out session BRKIPM-2265 to provide scalable BGP routing convergence.. oli ___ 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] Route Target Export Propagation Time
Richard, On a single PE with two VRF's, I create a RT export on VRF A and a RT import on VRF B, VRF A has some prefixes to export which appear in VRF B after approx 20 seconds, what process dictates the 20 seconds and is it configurable. Until recently, importing prefixes into VRFs was done in a periodic fashion (every 15 secs), you can (and should) tune it down to 5 seconds via bgp scan-time import 5 in the vpnv4 AF. Newer releases (as well as XR and NX-OS) do this event-driven, so newer releases don't need this.. Feature you want to look for is BGP Event-Based VPN Import oli ___ 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] 7200VXR no packets being routed w/ CEF enabled
My 7204VXR (NPE-300) is showing weird behaviour. When enabling CEF no packets are actually routed. Config minus passwords can be found here: http://pastie.org/private/ehsxoszlhqxo9lzftjzg This also happened before using the tunnel (when I just NATed out via the Dialer 1 interface) Any Ideas? (Other than using an older IOS version which I will try tomorrow) config looks ok, but can you please load an older release (12.3 mainline), NPE300 went end-of-life a long time ago.. oli P.S: I'll be at CCH later today, so ping me @oboehmer if it still doesn't work.. ___ 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] MPLS/VPN Loadbalancing with 2 CPE routers
Oliver, forget what I said... I've read will prefer instead of will never prefer :-( It's good to know that another provider is using this kind of architecture. It's not something we want to use for all our customers but this specific customer has some constraints which require to loadbalance their traffic. I guess we could also use OSPF and have the same cost for the path CE1 -- PE1 and the second path CE1 -- CE2 -- PE2. What would be the best in this case ? eBGP multihop or OSPF with costs ? if OSPF is an option, I would prefer this as it is cleaner and more natural routing, and no risk of running into loops. and with OSPF you could even come up with an EEM script on the CEs to adjust the CE-PE link metric based on the HSRP status, so you can even provide load-sharing when the HSRP master fails over to the standby (if such a failure scenario would still allow the standby CE to perform load-sharing, that is).. oli ___ 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] MPLS/VPN Loadbalancing with 2 CPE routers
I'm trying to find a way to use both links at the same time with only one HSRP master on the primary router... I had 2 ideas : 1/ use local pref to use one link for a specific dest network and the second link for another network obviously depends on number of networks and the distribution of traffic, most of it might only go to one destination, which wouldn't then be load-shared.. also cumbersome, so wouldn't go down this path. 2/ on the primary HSRP router, create 2 ebgp : one with the PE directly connected and one withe PE which is connected to the secondary router (ebgp multihop with static routes pointing to the secondary CPE) On the secondary router, use only one ebgp with the router directly connected. If the HSRP is going to be master on the secondary link, the traffic will be going to the second link only but I can tell to my customer that the loadbalacing is going to work only when the HSRP is master on the primary router.. This would work (and the caveat seems acceptable), I know of one SP who does this with their VPN customers. just make sure you configure a weight or localpref or something on the standby so you will never prefer an iBGP path over eBGP, or you would run into loops. An alternative would be eiBGP multipath on the active. I've never used this in a global routing context (it was developed for use on MPLS-VPN PEs), so pls try or, worst case, put the routes into a VRF on the CEs (vrf-lite). Same recommendation wrt loop avoidance applies here as well. Or use a GRE tunnel (shudder ;-) oli ___ 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] MPLS/VPN Loadbalancing with 2 CPE routers
Oliver, forget what I said... I've read will prefer instead of will never prefer :-( It's good to know that another provider is using this kind of architecture. It's not something we want to use for all our customers but this specific customer has some constraints which require to loadbalance their traffic. I guess we could also use OSPF and have the same cost for the path CE1 -- PE1 and the second path CE1 -- CE2 -- PE2. What would be the best in this case ? eBGP multihop or OSPF with costs ? if OSPF is an option, I would prefer this as it is cleaner and more natural routing, and no risk of running into loops. oli ___ 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] OSPF Conditional Inject
Hi I was working on a setup to test the OSPF conditional injection of a default routeIt worked me fine for Serial connection , but for Ethernet media it did not why ? because you didn't share the config? ;-) oli ___ 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] [IOS XR] export to default-vrf
Hi all, Did anyone get this to work on XR 4.3.2. vrf TEST address-family ipv4 unicast export to default-vrf route-policy default_policy_pass_all route-policy default_policy_pass_all pass end-policy [...] RP/0/RSP1/CPU0:#sh route vrf TEST B99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default), 17:54:43 is this an iBGP or an eBGP vrf route you are trying to export? Only external or locally originated routes are candidates to be exported from a VRF (anywhere, wether in global or into a different VRF), you need to do this on the originating PE. This rule is there to avoid loops, similar to standard BGP advertisement rule of only sending iBGP paths to external or RR-client peers. oli ___ 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] [IOS XR] export to default-vrf
Thx Oliver . router bgp xx address-family ipv4 unicast this was missing vrf TEST address-family ipv4 unicast redistribute connected metric 10 redistribute static metric 10 as the leak route is know via bgp ( in default vrf) and not connected/static ( as in vrf ) yes, this is expected, as any VRF import/export only applies to BGP routes, hence the source route needs to be in BGP in order to get exported. oli ___ 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] shaping 128 mbps - asr9k
Anyone know how to accomplish shaping traffic at a rate greater than 128 mbps ? When I apply the policy-map/class-map to an interface it fails with this message. 'Cannot support child/flat shape rate 128Mbps' can you please share the configuration you are trying to apply, including policy-maps and where you want to apply this? oli ___ 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] ISP / MPLS POP design
On Wednesday, November 06, 2013 04:43:22 PM Oliver Boehmer (oboehmer) wrote: No, and neither does ISIS, and I am not aware of any such a requirement. Seriously? Yeah, millions of IGP entries is not a typical requirement, AFAIK. BGP issues don't necessarily propagate to the IGP :-). I think any IGP would fall over before it gets to 1,000,000 entries, simply because of the nature of the link-state protocol design. no doubt here.. hence I really wonder who would ever put forward such a requirement (and Adam added a smiley, so not sure ;-).. We have unified-mpls to scale to very large MPLS domains, but the IGP certainly doesn't need to scale anywhere close to this.. oli ___ 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] ISP / MPLS POP design
no doubt here.. hence I really wonder who would ever put forward such a requirement (and Adam added a smiley, so not sure ;-).. We have unified-mpls to scale to very large MPLS domains, but the IGP certainly doesn't need to scale anywhere close to this.. RFC 3107, I'm assuming. yep, along with multi-area/level/domain IGP.. Even BGP-LS wouldn't necessarily scale, as it's exported data from the IGP (which won't scale to millions of routes anyway). Hmm, I consider BGP-LS only to distribute existing topology information to clients (for example some controllers or PCE or whatever is interested to learn about the network topology), not to update the RIB/FIB. Even the data centres are turning to BGP to scale east-west routing away from the IGP's (draft-lapukhov-bgp-routing- large-dc-06). of course, what else? ;-) oli ___ 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] ISP / MPLS POP design
On Thursday, November 07, 2013 11:10:37 AM Oliver Boehmer (oboehmer) wrote: yep, along with multi-area/level/domain IGP.. In each island, however, multi-level/multi-area IGP's break MPLS-TE. well, there is no free lunch ;-) Maybe that will be solved by Segment Routing :-). or by mutli-area TE, engineered by PCE/WAN-Orchestration.. oli ___ 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] ISP / MPLS POP design
On 11/6/13 4:52 PM, CiscoNSP List wrote: Don't forget to use per PE/VRF RDs. re per PE RD's - So you are suggesting for each PE, I use unique RD's for a given VRF? I could see this would assist with troubleshooting(Being able to see which PE a route originated from), are there any other benefits/why is this recommended? (Disclaimer: coffee not brewed yet) At least with route reflectors and possibly to some degree with confederations (see disclaimer), you lose the ability to load-share to a prefix with non-unique RDs, as the RR boils multiple paths down to one best path which is reflected to other nodes. The unique RD is embedded in the 96-bit vpnv4 route and therefore the ingress node (potentially) can see multiple load-sharable routes for which multiple outer labels can be rotated. strong ack, unique RDs is a strong recommendation, also for convergence. When you have an alternate path available, you can switch over to it quickly (BGP PIC Edge), whether you're loadsharing across the multiple paths or not.. oli ___ 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] ISP / MPLS POP design
I didn't want to chime into the usual OSPF vs ISIS debate, but the first statement is not (or at least has been for a while no longer) true. So does OSPF already support 1M routes as requested by an unnamed ISP? :))) No, and neither does ISIS, and I am not aware of any such a requirement. Seriously? oli ___ 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] ISP / MPLS POP design
IS-IS can scale to a larger number of devices in a single area and overall network. Really depends on how many devices you are talking about. For smaller deployments it usually comes down to who is supporting the network and what they are more familiar with. I didn't want to chime into the usual OSPF vs ISIS debate, but the first statement is not (or at least has been for a while no longer) true. It comes down to feature availability (there are just some things which are slightly different, or are coming out at different times) and, as you rightfully say, your staff's familiarity with either. oli ___ 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] XR 12000/GSR - 4.2.3 VRRP IPv6 Global virtual address.
I am looking for VRRP support on XR - 12000 / GSR with global IPv6 virtual address to achieve something like below . But seems XR is not supporting it on 12K . Can anyone confirm what is supported on XR for 12000s ? [...] RP/0/9/CPU0:PE-test7.bl(config-vrrp-virtual-router)#show configuration failed Tue Nov 5 02:29:22.517 IST !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below. router vrrp interface GigabitEthernet0/0/0/3.404 address-family ipv6 vrrp 4 address global 2001:954:0:f::1:1 !!% 'vrrp' detected the 'warning' condition 'No Primary VRRP IP address exists for this VRID' ! ! vrrp on xr requires a linklocal address to be configured, best use autoconfig: router vrrp interface GigabitEthernet0/0/0/3.404 address-family ipv6 vrrp 4 address linklocal autoconfig address global 2001:954:0:f::1:1 Hope this works oli ___ 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] FAT PW between 7600 - ASR9K
Does anyone have experience with FAT PW between 7600 and ASR9K? The ASR9K supports it for sure and it has been verified. The 7600, according to the doc, supports it only for VPLS with the addition of a global command platform vfi load-balance-label vlan . We have implemented all the above, the pseudowires come up, but the flow label capability is not negotiated between 7600-ASR9K. Apart from that, there is no traffic flow over the pseudowires in the direction 7600-ASR9K. After we remove the platform vfi load-balance-label vlan command from the 7600, traffic starts flowing. looks like the 7600 doesn't support signalled FAT PW today, hence you need to configure static flow-label (load-balancing flow-label both static) on the ASR9k peer. oli ___ 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] FAT PW between 7600 - ASR9K
George, Oliver, since the documentation is very very limited, I'd appreciate if you could provide some info on how each PE will identify the flow labels. Is there a predefined range that is used only for the flow labels as Phil previously mentioned? you can check http://tools.ietf.org/html/rfc6391 how this works, there are no constraints on the flow label value other than it must not be a reserved label value (0-15). The label value is only significant for the encapsulating/ingress PE, it just ensures to allocate and use the same label for all indivisible flows, to ensure those flows are sent via the same ECMP path. Section 3 of the RFC talks a bit about who the PE should allocate and assign labels. The egress PE just needs to know that there is a flow label present on the PW (statically or signalled via LDP), and it just pops it. hope this helps.. oli ___ 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] Peering between VRF's in the same 6500 VSS
not sure how you set this up, but best force an eBGP session between the two VRFs, using a config like below which also uses unique BGP router-ids per VRF, otherwise the updates would be dropped.. oli int interface1 ip vrf forwarding VRF-A ip address 10.0.9.1 255.255.255.0 int interface2 ip vrf forwarding VRF-B ip address 10.0.9.2 255.255.255.0 ! router bgp 65000 address-family ipv4 vrf VRF-A neighbor 10.0.9.2 remote-as 65112 neighbor 10.0.9.2 local-as 65111 no-prepend replace-as neighbor 10.0.9.2 activate bgp router-id 10.0.9.1 exit-address-family ! address-family ipv4 vrf VRF-B redistribute connected neighbor 10.0.9.1 remote-as 65111 neighbor 10.0.9.1 local-as 65112 no-prepend replace-as neighbor 10.0.9.1 activate bgp router-id 10.0.9.2 exit-address-family ! On 04/10/2013 11:09, Alexander Wågberg alex.wagb...@gmail.com wrote: Hi, I have the following scenario: ASR1002X -- VRF-A -- 6500 -- IPS -- 6500 -- VRF-B -- ASR1002X The ASR1002X to the left is the same as the one to the right, as well as the 6500. The IPS in this picture acts like a loop cable. Between the vrf's I've setup a BGP-peer, the goal is that traffic should flow though the IPS when going from vrf A to B and B to A. The problem is that, prefixes sent from the ASR in both VRF's are not learned in the other vrf on the ASR. The 6500 learns routes from both vrf's and announce routes to the ASR in both vrf's. The ASR is also route-reflector-client for both vrf's. Why can't I see routes from vrf B in vrf A in the ASR ? BR, -- Alexander wberg Wågberg ___ 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] Question configure QoS on ES20 Card, Cisco 7609
Nam, as Tony already said, deny clauses are not supported in QoS classification ACLs on this linecard. So you need to change your qos semantic. Assuming deny was supported, your current qos policy semantic looks like if( destination is not in (1.52.x.x, etc.) ) then police to 1 mbps else police to 2 mbps if that is the case, you can change the config to access-list foo permit ip any 1.53.0.0 0.0.255.255 access-list foo permit ip any 1.52.0.0 0.0.255.255 access-list foo permit ip any 1.54.0.0 0.0.255.255 access-list foo permit ip any 1.55.0.0 0.0.255.255 ! class-map FOO match access-group foo ! policy-map BAR class FOO police cir 200 bc 10 be 10 conform-action transmit exceed-action drop violate-action drop class class-default police cir 100 bc 10 be 10 conform-action transmit exceed-action drop violate-action drop If the policy is more complex, it could get trickier.. oli On 03/10/2013 05:13, Nam Nguyen nhna...@gmail.com wrote: Dear all ! At the end of ACL 161, I have defined permit ip any any: access-list 161 deny ip any 1.53.0.0 0.0.255.255 access-list 161 deny ip any 1.52.0.0 0.0.255.255 access-list 161 deny ip any 1.54.0.0 0.0.255.255 access-list 161 deny ip any 1.55.0.0 0.0.255.255 access-list 161 permit ip any any I think it's ok but I couldn't see the counter. Please help me Thanks Nam On Thu, Sep 26, 2013 at 7:28 PM, Nam Nguyen nhna...@gmail.com wrote: Hi ! at the end of acl i have defined permit ip any any: - i need to block some traffic and permit the rest Nam Nguyen On 26-09-2013, at 19:02, Tony td_mi...@yahoo.com wrote: Hi, The error message seems to be fairly clear, you can't have DENY statements in ACL. As to why you are not seeing anything in your counters, you only have DENY statements and the end of every ACL is an implicit deny ip any any this means that your ACL's will not match anything at all, so nothing will go into your class. What are you trying to achieve ? regards, Tony. - Original Message - From: Nam Nguyen nhna...@gmail.com To: cisco-nsp@puck.nether.net Cc: Sent: Thursday, 26 September 2013 8:21 PM Subject: [c-nsp] Question configure QoS on ES20 Card, Cisco 7609 Hi all ! I have some problem when configure QoS on Cisco ES20 card: - When I applied policy-map on sub-interface (egress), I see error message: %G_QOS_CLASSIFY-DFC2-3-QOS_CONFIG: error detected: Can not support deny ace in ACL (161) - When I applied policy-map on sub-interface (ingress), It's okay but I cann't see the counter. Below is example: class-map match-all UP match access-group 161 class-map match-all DOWN match access-group 160 class-map match-any MATCH_ALL match access-group 100 policy-map 3M (This policy-map: I can see counter when issue show policy-map interface) class MATCH_ALL police cir 300 bc 30 be 30 conform-action transmit exceed-action drop violate-action drop policy-map ABC (This policy-map apply to ingress ok but I cannot see counter when issue show policy-map interface ) class UP police cir 100 bc 10 be 10 conform-action transmit exceed-action drop violate-action drop class MATCH_ALL police cir 2000 bc 200 be 200 conform-action transmit exceed-action drop violate-action drop Extended IP access list 100 (class MATCH_ALL) 10 permit ip any any Extended IP access list 160 (class DOWN) 10 deny ip 1.53.0.0 0.0.255.255 any 20 deny ip 1.52.0.0 0.0.255.255 any 30 deny ip 1.54.0.0 0.0.255.255 any 40 deny ip 1.55.0.0 0.0.255.255 any ... Extended IP access list 161 (class UP) 10 deny ip any 1.53.0.0 0.0.255.255 20 deny ip any 1.52.0.0 0.0.255.255 30 deny ip any 1.54.0.0 0.0.255.255 40 deny ip any 1.55.0.0 0.0.255.255 50 deny ip any 101.53.0.0 0.0.63.255 ... Result show policy-map interface 7609#sh policy-map int Po1.XYZ Port-channel1.2304332 Service-policy input: ABC Class-map: UP (match-all) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: access-group 161 police: cir 1000 bps, bc 100 bytes, be 100 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop violated 0 packets, 0 bytes; actions: drop conformed bps, exceed bps, violate bps Class-map: MATCH_ALL (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: access-group 100 police: cir 1 bps, bc 1000 bytes, be 1000 bytes conformed 0 packets, 0 bytes; actions: transmit
Re: [c-nsp] asr9k police config 8k - seeing 38k allowed
On 09/09/2013 22:31, Aaron aar...@gvtc.com wrote: Interesting, it says burst 1598 bytes , so is there a built-in burst allowance ? default burst is 100ms worth of CIR, with a minimum of ~1600 bytes (as in your example). Also says conform 65 kbps, what is that ? minimum CIR is not 64000 bps, it is actually 65536. oli ___ 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] OSPF Database
Hi all , I have a small OSPF topology with one ASBR connected to EIGRP AS 12everything is working fine , my question is can i from the show ip ospf database outputs know what is the external routing protocol ? such as in my case it's eigrp ? no, they show up as external routes, just as if you redistributed static or connected. you can't distinguish them per-se.. you could consider setting a tag during the redistribution which will tell you where they came from.. oli ___ 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] asr9k police config 8k - seeing 38k allowed
Is CIR 128k in this policy ? if so, then is this correct ? 128k = 128 * 1024 = 131,072 bps it's actually 128,000 bps.. kilo factor is 1000 in bandwidth context. Then you mentioned default burst is 100ms worth of CIR... is this correct ? 100ms worth of CIR is 131,072 / 10 = 13,107.2 bits = 13,107.2 /8 = 1,638.4 bytes it would be 128000/(10*8) = 1600.. If this is all true why does it still show 1598 bytes instead of the new burst value of 1638 bytes ? I don't know why it's 2 bytes off :-} oli ___ 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] asr9k police config 8k - seeing 38k allowed
On 09/09/2013 20:16, Aaron aar...@gvtc.com wrote: Why is this allowing 38k to flow if I'm policing at 8k ? My understanding of policing (especially policing without any bursting allowed) is that it's a strict action not allowed to be exceeded. minimum policing rate on asr9k is 64 kbps.. can you check show qos interface g0/0/0/10 output? oli ___ 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] EIGRP two ASs
Hi all , I have the below topologyR1 - R2 - R4R1 - R3 - R4The first path operates in AS 12 and the second path operates in AS 13Now , I advertised Loopback 0 on R4 (4.4.4.4/32) in both AS numbers , what I can see in R1 IP routing table is only one path and in the topology table I can see two entries but the second one which is the not selcted one shows FD inacesible , I shut down the interface and I could learn the prefix via the second one , activated again and as it preempted , what is the reason behind selesting the first path ? all the links are similar If I understand correctly, R1 learns the same prefix via two different routing sources (eigrp 12 and eigrp 13). IOS can only install the route from one routing source, so it needs to make a decision, and uses the administrative distance. If the two sources use the same distance, the behaviour is undefined, usually the first one wins. With two EIGRP processes with the same admin distance, competing for the installation, IOS selects the path received from the lower numbered AS/process ID (see http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012 dac4.shtml#eight2). oli P.S: I thought I heard that the selection also considers EIGRP composite metric (which is an exception for EIGRP as normally protocol metric is not considered when multiple processes with the same AD compete), but not sure about this.. ___ 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] IOS XR AAA
On 20/05/2013 17:00, Shane Heupel sheu...@twlakes.coop wrote: We just purchased a couple of ASR9Ks and we're trying to set up AAA to our free radius servers. We have the ASRs configured to authenticate against the AAA servers but are having some trouble with the user attributes being passed between the ASRs and AAA server that define which task group each user is assigned. Does anyone have a radius configuration that they would mind sharing? Example user: username bob group netadmin group sysadmin group cisco-support you need to include Cisco-avpair = shell:task=#netadmin,#sysadmin,#cisco-support in the profile.. If you send this profile to non-XR system, they might choke, so you might need to make it optional via Cisco-avpair = shell:task*#netadmin,#sysadmin,#cisco-support don't have a full radius example handy right now, but maybe the above will help.. oli ___ 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] RIB-failure(2) - next-hop mismatch - In VRF context
On 07/05/2013 10:30, Adam Vitkovsky adam.vitkov...@swan.sk wrote: Hi folks, I'd like to ask what is the meaning of RIB-failure(2) - next-hop mismatch - in context of a VRF table please #sh ip b vpnv4 vrf voice1 10.100.2.0 BGP routing table entry for 16160:402:10.100.2.0/28, version 22965354 Paths: (1 available, best #1, table voice1, RIB-failure(2) - next-hop mismatch) Advertised to update-groups: 9 Local, imported path from 16160:454:10.100.2.0/28 10.101.1.2 (metric 30) from 10.101.1.2 (10.101.1.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:16160:45400 RT:16160:50001 mpls labels in/out nolabel/667 #sh ip b vpnv4 vrf voice1 rib-failure NetworkNext Hop RIB-failure RIB-NH Matches Route Distinguisher: 16160:402 (default for vrf voice1) 10.100.2.0/28 10.101.1.2 Admin distance = 255 n/a which version do you run? Can you share show ip route 10.101.1.2 show ip route vrf voice1 10.101.1.2 show ip route vrf voice1 10.100.2.0 and you are seeing more BGP VRF routes installed with next-hop 10.101.1.2? there is CSCsi11807 which shares the same problem signature, but can't tell without more details. oli ___ 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] difference between WS-X4306 and WS-X4306-GB(Cisco 4500 platform) modules
On 07/05/2013 11:47, Martin T m4rtn...@gmail.com wrote: Hi, any ideas what is the difference between WS-X4306 and WS-X4306-GB modules? sh module output from WS-C4506 switch: [Š] I checked the sh platform chassis and sh platform hardware information plus compared sh int Gi3/3 capabilities and sh int Gi4/3 capabilities output, but there seems to be no difference between WS-X4306 and WS-X4306-GB.. indeed, there is no capability differences, it was a cosmetic name change with hw-rev 2.2 (your -GB is hw-rev 3.0, the other is 2.0).. oli ___ 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] NP108 Interchangeable 5350XM and 5400XM
Hi Everyone, Does anyone know if an NP108 is interchangeable between the 5350XM and the 5400XM? I’ve got a dead one in a 5350XM and could borrow one from a 5400XM if they are interchangeable as a quick fix. yes, the datasheets on CCO (herehttp://www.cisco.com/en/US/prod/collateral/iad/ps501/ps6268/product_data_sheet0900aecd802f0778.html and herehttp://www.cisco.com/en/US/prod/collateral/iad/ps505/ps6269/product_data_sheet0900aecd802efc92.html) state support of AS5XM-VUFC-108NP on both platforms.. oli ___ 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] ipsla - latency - related to cellular backhaul
On 29/04/2013 15:23, Aaron aar...@gvtc.com wrote: Thanks Adam, sh lpts pifib hardware police location 0/0/cpu0 shows all 0's in the drop column, but at the bottom it shows... RP/0/RSP0/CPU0:9k#sh lpts pifib hardware police location 0/0/cpu0 | in drop Mon Apr 29 08:22:55.180 CDT Packets dropped by deleted entries: 71429 ...any idea what that is ? it's a cumulative drop counter for dynamically created entries, for example lpts entries which are created for icmp replies (following a CLI ping), and which are later removed.. upon removal, the drop counters are added to the above counter.. oli ___ 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] community on bgp update
On 29/03/2013 16:46, Riccardo S dim0...@hotmail.com wrote: Hi do I get the same result with route-map test-1 and test-2 in setting these community on BGP update ? *** route-map test-1 permit 10 match ip address prefix-list site-a set community 1:1 set community 1:2 additive *** route-map test-2 permit 10 match ip address prefix-list site-a set community 1:1 continue ! route-map test-2 permit 20 match ip address prefix-list site-a set community 1:2 additive the result might be different, as the test-1 config results in this: route-map test-1 permit 10 match ip address prefix-list site-a set community 1:1 1:2 additive ! and this one would add both communities to any communities already on the route, while prefixes processed by test-2 will have only 1:1 1:2, with all other communities removed. And could you please give me an example of a route-map that match the route marked before with 1:1 and 1:1 + 1:2 ? I was wondering if this is ok: ip policy-list PERMIT100 permit match community 1 ! ip policy-list PERMIT200 permit match community 2 ! ip community-list 1 permit 1:1 ip community-list 2 permit 1:2 ! ! ! route-map only1-1 permit 10 does it match only if it's present 1:1 ? match policy-list PERMIT100 no, it will also match 1:1 1:2, you would need to use match community 1 exact-match in the policy-list. route-map 1-2 permit 10 does it match only if are presend 1:1 AND 1:2 ? match policy-list PERMIT100 match policy-list PERMIT200 no, you would need to do match on ip community-list 12 permit 1:1 1:2, which creates an AND. hth oli ___ 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] Route-Reflector Sub-optimal Routing
Does anyone know exactly what's meant by sub-optimal routing issues ? it means that a RR makes a routing decision on its client's behalf, and its best path might not be necessarily the one the clients would have picked (especially when the decision is based on the IGP metric to the next-hop). Is there any method to allow the Route-Reflector to send all routes to clients (not the best one) ? yes, it's called BGP add-path, but consider the consequences of additional state/paths to be carried on your RR-clients.. oli ___ 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] BGP neighbor fall-over vs BFD
Can someone shed some light on this? What is fall-over really doing and when might it be useful? sorry for the confusion ;-) neighbor fall-over (without the BFD keyword) is for multihop/non-directly-connected peers like the default behaviour fast-external-fallover for directly connected neighbours: the session will be torn down. It works by monitoring/tracking the next-hop address, so if something removes the route to the peer, the session will be torn down. It works pretty much the same way as Next-hop-Tracking (monitoring the RIB), but it tears down the session (while NHT only declares the nexthop as invalid). fall-over bfd isn't monitoring the RIB, it uses BFD to monitor neighbour reachability liveliness, and it will tear down the session if BFD signals a failure. So fall-over is actually much more than a single feature.. did I apologize for the confusion? ;-) oli ___ 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] BGP neighbor fall-over vs BFD
In the case I'm thinking of using it, we do all over our internal BGP peering to loopbacks, which are in OSPF. If we enable fallover, it sounds like the peer will be torn down as soon as that next hop is removed from the routing table. Which is generally not something folks do in iBGP, there you would use NHT and mark your NH as invalid. No need to tear down the session. One problem we have that I'm trying to solve is that we also have a null0 static route used for aggregation for the loopback addresses. This static route stops the BGP routes from being invalidated until the peer goes down because the next hop is technically still reachable, although via Null0. I'm pondering the use of selective next-hop filtering so that only /32 routes in OSPF can be used to validate next hops, but I wonder if just enabling fallover would be better option. Nope, I would recommend enable selective address tracking (next-hop route-map FOO), as Bruce just reasoned.. We aren't using BFD right now. Not sure why. It seems like using fallover with BFD would be an excellent solution to this problem. Until very recently, BFD has only been implemented for adjacent neighbours. so in most cases, BFD wouldn¹t work on most iBGP sessions.. oli ___ 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] IOS-XR OSPF path selection
the ancient, but still valid OSPF Design Guide at http://tools.cisco.com/squish/0D377 shows an example how E1 and E2s are installed.. perhaps this: http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a008009 4e9e.shtml (doesn't require a login) oh, sorry, wasn't aware that the tool requires a login :-} oli ___ 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] IOS XR and router rib rump always-replicate
On 01/03/2013 10:58, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 1 Mar 2013, Christian Meutes wrote: On 01.03.2013, at 10:01, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 1 Mar 2013, Christian Meutes Do you have your sources addresses in IGP? Nope, BGP SAFI unicast. Well, your experience contradicts mine. I have had to solve issues with multicast not working and started working when the sources were put in SAFI multicast with as late software as XR 4.2.1. I'll defer to someone more knowledgable to explain how this really works. Once you enable the mcast AF in your IGP or BGP, IOS-XR will populate the muRIB, and PIM will use this one for RPF (before it used the unicast RIB/uRIB). This requires that all sources will be in the muRIB. This is different from IOS where RPF would fall back to the unicast RIB, as Michael described. The rump always-replicate command will replicate uRIB to muRIB, so we effectively achieve the IOS behaviour. oli ___ 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] IOS-XR OSPF path selection
According to the IOS-XR documentation on OSPF: ASBR routes can be advertised as a Type 1 or Type 2 ASE. The difference between Type 1 and Type 2 is how the cost is calculated. For a Type 2 ASE, only the external cost (metric) is considered when multiple paths to the same destination are compared. For a Type 1 ASE, the combination of the external cost and cost to reach the ASBR is used. Type 2 external cost is the default and is always more costly than an OSPF route and used only if no OSPF route exists. This seems to not be the standard behavior of IOS or NX-OS. With IOS or NX-OS you can influence type-1 or type-2 routes via interface cost. But in IOS-XR only type-1 are effected by interface cost, but not type-2. huh? no compliant OSPF router (no matter which OS/brand) should consider the cost to reach an ASBR when installing a type-2 external in its RIB, so not sure what you mean by the above? can you give an example? the ancient, but still valid OSPF Design Guide at http://tools.cisco.com/squish/0D377 shows an example how E1 and E2s are installed.. oli ___ 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] pros and cons for IPTV multicast in rosen-mvpn vs GRT
Are there any cons for running IPTV in draft-rosen-mvpn as opposed to global routing table current implementation makes it generally easier to reduce loss-of-connectivity after link/node failures using IGP Fast Convergence compared to BGP-based convergence when the mcast sources/TV headends are visible in BGP. You can also use p2mp-TE-FRR when mcast is in the global routing table (not sure if things have changed there). MoFRR is also targeted for PIM deployments in the global table, and some live-live approaches might not work as well if the sources aren't visible from the core/P nodes. Why do you consider putting it into a VRF? I acknowledge that reasoning is highly dependent on specific network topology and requirements.. oli ___ 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] pros and cons for IPTV multicast in rosen-mvpn vs GRT
easier to reduce loss-of-connectivity after link/node failures using IGP Fast Convergence compared to BGP-based convergence. Yes the convergence time would be slower I suppose as a mere addition of another protocols to the picture. Though if you consider the whole LoC timeframe the IGP or BGP convergence is one of the smallest portions -compared to the PIM convergence time. well, that really depends on the failure and platform, but BGP control-plane convergence is generally a magnitude higher than PIM. So I would not discount this if you're after sub-second convergence. IOS-XR and halfway recent IOS /XE releases use an source-based, event-triggered RPF check and will be able to send out the required PIM Joins quite fast, so the time difference of BGP vs. IGP will make a difference.. Core link failures would still be handled quickly, here we talk about converging the MDT S,G.. Why do you consider putting it into a VRF? Well the main concern my boss has is the exposure of core/global routing table to set-top-boxes -as a potential attack vector Hmm, if the global routing is limited to the IP-TV Vlan, locking it down via generic ACLs is easy as the traffic sources and type will be very limited. oli -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Monday, February 18, 2013 4:25 PM To: Adam Vitkovsky; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] pros and cons for IPTV multicast in rosen-mvpn vs GRT Are there any cons for running IPTV in draft-rosen-mvpn as opposed to global routing table current implementation makes it generally easier to reduce loss-of-connectivity after link/node failures using IGP Fast Convergence compared to BGP-based convergence when the mcast sources/TV headends are visible in BGP. You can also use p2mp-TE-FRR when mcast is in the global routing table (not sure if things have changed there). MoFRR is also targeted for PIM deployments in the global table, and some live-live approaches might not work as well if the sources aren't visible from the core/P nodes. Why do you consider putting it into a VRF? I acknowledge that reasoning is highly dependent on specific network topology and requirements.. oli ___ 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] MPLS TE explicit-path: secondary ip as next-address
On 05/02/2013 11:03, Artyom Viklenko ar...@viklenko.net wrote: 05.02.2013 10:30, sth...@nethelp.no пишет: New ip addresses was configured as secondary on interfaces in question. These new subnets (/30) appear in routing table, cef, etc. Network statement also was added to ospf configuration. Note that it at least *used* to be the case that OSPF wouldn't form adjacencies over secondary addresses. I don't know if this limitation still holds, but it could be relevant to your case. […] But it doesn't in output of 'show mpls traffic-eng topology' like any other secondary subnets. This lead to errors establishing path. indeed, that's the reason CSPF won't find a path when you reference the secondary in the path.. Don't think you can add those to the topology, so the only approach would be to work with alternate path options and re-oprtimization which would use a temporary path around the links you're migrating. Or maybe you don't have that much traffic during low-peak hours that you could do away without the tunnels when you change the links? oli ___ 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] VPDN multihop/forwarding not working
Well, have you defined any of these other realms on the Radius server (with the static cisco password)? If you don't, and if you don't have a vpdn-group with a request-dialin matching their realm, nothing will break, adding the vpdn authorization .. on those vtemplates will just make sure the LNS no longer sends these Radius requests (with the domain).. have you checked the Radius traces since you enabled vpdn multihop? If you have users with @ or / on other vpdn-groups, you will see those? Our current setup is - We have multiple realms all configured on our radius server (no cisco password, just each DSL account i.e. FNN@realm and a random system generated password), and approx 15 vpdn-groups on our LNS that connect to the carriers LACs all accept-dialin and all using virtual-template7 eg: well, if all are referencing virtual-template 7, this is where you can put vpdn authorization LOCAL_AUTH. And as you are currently not providing any VPDN multihop, this configuration shouldn't break anything as the only thing it would affect would be radius-based tunnel authorization. So, we are adding a new dsl realm, connection requests for the new realm will be coming from the same LAC's, but we want to not auth the new realm via our existing radius server - We want our LNS to create an L2TP tunnel to another LNS for this new realm (And then this other LNS will authenticate the DSL tails via another radius server. Right. So I would just add a new vpdn-group with a request-dialin section with an appropriate domain, just as you configured in your vpdn-group TEST you provided earlier.. the vpdn authorization LOCAL_AUTH will ensure the LNS will look for it. oli ___ 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] VPDN multihop/forwarding not working
Thanks Oli, sorry for not mentioning it, but the command needs to be applied to the vtemplate referenced in the vpdn-group which terminates the original L2TP tunnel from the LAC. You might want to consider putting this on all vtemplates, as this could avoid quite a few Radius requests in case the other user names contain realms (@domain). As we terminate a lot of other realms from various LAC's - Adding this wont break any of the existing realms? (We have a number of vtemplates, and vpdn groups as we already use a number of different realms.but they are all locally terminated on this LNS) Well, have you defined any of these other realms on the Radius server (with the static cisco password)? If you don't, and if you don't have a vpdn-group with a request-dialin matching their realm, nothing will break, adding the vpdn authorization .. on those vtemplates will just make sure the LNS no longer sends these Radius requests (with the domain).. have you checked the Radius traces since you enabled vpdn multihop? If you have users with @ or / on other vpdn-groups, you will see those? So I need to: Add; vpdn authorization LOCAL_AUTH under the virtual template referenced on the vpdn-groups this new realm will use, and for this new realm our LNS should then create an L2TP tunnel to the initiate-to ip under the vpdn conf for the new realm? yes. I think you can put both functions (accept-dialin and request-dialin) in the same vpdn-group? as I said, my vpdn skills are rusty.. oli ___ 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] ISIS BFD not Supported on CRS-3 ?
Hi C-NSP Members, We are a service provider running Cisco CRS-3 in our IP/MPLS core. Due to protection, we have recently added another 10Gbps link connecting 2 Cisco CRS-3 core routers, namely CR-A and CR-B. The config below are on CR-A and CR-B has similar config. Question : 1. Is this a known issue that BE interface does not support BFD ? well, yes. IOS-XR only supports BFD for a bundle-vlan, or, what would be ok for you, BFD for each bundle-member. This way, BFD will run on each physical member, and the system will remove the member from the bundle if BFD fails. If the last member leaves, the bundle goes down, and the protocols will see the link going down. This is IMHO superior as each physical link is tested individually. Please check http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.0/interfaces/co nfiguration/guide/hc40bifw.html#wp1040061 for instructions.. please note that this feature requires XR on both ends of the links. oli ___ 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] XR conditional default advertisement
Adam, Is there really no conditional default advertisement possibility in IOS XR? I mean towards vpnv4: (config-bgp)#vrf inet (config-bgp-vrf)#default-information originate ? cr in BGP, this command by itself does not originate a default, it just enables the redistribution of 0.0.0.0/0 or ::/0 into BGP from another protocol. this is not specific to vrf, same issue for global/ipv4/ipv6. The only way of generating a conditional default is towards a neighbor via the neighbor default-originate route-policy FOO where the RPL FOO can use the rib-has-route statement/command. Unfortunately, you can't use the rib-has-route in a redistribute or network statement or in neighbor filters.. oli ___ 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] VPDN multihop/forwarding not working
Hi Guys, Have a 7200 (LNS) that terminates DSL tails from multiple carriers (Using our radius for auth) - Attempting to forward connection requests for a specific realm to an alternate LNS (So create an L2TP tunnel) Have the following vpdn setup, but the tunnel is not getting created to the initiate-to IPand if the new realm DSL accounts are created on our radius server, they auth? when you configure vpdn multihop, the LNS will try to authorize the domain part of the user (with password cisco) against the configured network authorization method on the vtemplate to retrieve the tunnel forwarding information. IN your scenario this is radius, and the locally configured information is ignored. so either you create a Radius profile like testrealm.com.auPassword = cisco Service-Type = Outbound, Cisco-avpair = vpdn:tunnel-type=l2tp, Cisco-avpair = vpdn:tunnel-id=TEST7200, Cisco-avpair = vpdn:ip-addresses=x.x.x.x, Cisco-avpair = vpdn:source-ip=y.y.y.y, Cisco-avpair = vpdn:l2tp-tunnel-password=xxx or you do something like aaa authorization network LOCAL_AUTH local ! interface virtual-template number vpdn authorization LOCAL_AUTH to use the locally configured tunnel information. my vpdn knowledge is a bit rusty, so not 100% sure if this is still how it's supposed to work ;-) oli ___ 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] VPDN multihop/forwarding not working
Thanks very much Oli, aaa authorization network LOCAL_AUTH local interface virtual-template number vpdn authorization LOCAL_AUTH I've created a virtual-template (Using LOCAL_AUTH as you have suggested), but I am unable to apply the template to the vpdn-group? i.e. with request-dialin configured I am not given an option to add the virtual-template - if accept-dialin is configured (As per all our other vpdn-group setups), a virtual-template can be applied? sorry for not mentioning it, but the command needs to be applied to the vtemplate referenced in the vpdn-group which terminates the original L2TP tunnel from the LAC. You might want to consider putting this on all vtemplates, as this could avoid quite a few Radius requests in case the other user names contain realms (@domain). oli ___ 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] Difference between ISIS NSR and ISIS NSF Cisco-Style
I have a one more query with HA mode . can we configure both NSR and NSF together , and if so during switchover which one is triggered first NSR or NSF . you can either configure nsf cisco or nsf ietf in ISIS, so one or the other. The only common thing is that a router configured with nsf cisco will still able to help a restarting nsf ietf router to perform its graceful restart, so the nsf cisco box will also advertise IETF-GR capability in the IIH.. I have two reasons for going into this deployement approch. 1 If someof my neighbour is not NSF capable or by mistake NSF gracefull config is not enabled or removed from any neighbour.NSR will take care for those neighbours. 2 During testing on CRS with scalability figures ,after switchover it was taking 4 mins of time to fully sync all the routing information with standby and if there is one more switchover during that time span , NSF can take care. What do you suggest as best practice deployements for NSR/NSF considering above two points. As said, you can't enable both, one or the other. So you can't address both concerns, and need to evaluate which one you care more about. I would argue that the 2nd one is more of a corner case, and would advocate nsf cisco to be independent from any neighbour NSF capability support.. oli ___ 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] IOS-XR OSPF rapid repeating error.
Lee, I was wondering if anyone has seen this and if it is caused by a bug or a security hole. OSPF process is in an endless loop of errors that I was only able to fix with a reboot. I could not restart the OSPF process as it would just hang for 60 seconds and then give up. This problem takes the CPU to 100% when this OSPF problem happens and for whatever reason, happened on two routers at the same time. I did some searching but was never able to find an actual answer as to the cause. What I find odd is that two routers would end up with the same problem at the same exact time if it is a bug and if it is a security hole, that I was not able to find the details on it. RP/0/9/CPU0:Jan 15 19:27:40.781 : ospf[1009]: %ROUTING-OSPF-3-INTERNALERR : Internal error, path id out of range you're hitting a known issue CSCtn00523 (details on CCO), there is an OSPF Umbrella SMU avaliable for download on CCO, which fixes this an other OSPF issues in 4.0.1 (CSCts31308). oli ___ 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] Flexible Netflow - Set the v9 Source ID?
David, I'm Just looking at Cisco's IPFIX implementation using the new Flexible Netflow CLI, and wondering how one would configure the Source ID (actually called the Observation Domain ID) in the header. [...] it seems from this that is is generated and not flexible (I.e user settable), I'd very much like parity with existing exporters I have which can indeed set this (and I make good use of it) , simply sourcing the packets from a set/known IP isn't really what I'm after. May I ask how you're planning to use this field? I've always considered it nothing more than a discriminator to ensure uniqueness when you have multiple flow exporting entities on a single router (linecards on an ASR9k or CRS for example), and for troubleshooting purposes. Please note that all Netflow export packets are sourced by the configurable source IP address within the flow exporter. oli ___ 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] NBAR on SVI on 7600 w/ Sup720
Alex, not sure what you're looking for. Not supported means you're on your own, use it at your own risk and expect things can go wrong. It could be switched in software in one release (which might be fine and serve your purpose as long as the traffic stays below given threshold or it doesn't affect other features you are using), or hell could freeze over in other releases, we don't test this. So I guess you could call your setup mis-configured. you will not find a document stating NBAR implementation is software based on the PFC/7600. oli On 22/01/2013 10:47, Alex K. nsp.li...@gmail.com wrote: Hi Oliver, Exactly - not supported. It implies that *if it works (not on SIP-200), it must be software'. I came across this document before I sent the question. As it seems, that what I'll use. I'm looking for a document that say explicitly 'NBAR implementation is software based' to be sure we didn't run into some sort of bug/mis-configuration. Thank you. Best Regards, Alex. On Jan 22, 2013 8:04 AM, Oliver Boehmer (oboehmer) oboeh...@cisco.com wrote: Alex, On 22/01/2013 01:19, Alex K. nsp.li...@gmail.com wrote: Hi Pete, We're running 12.2(33)SRA6. On SIP-200 it's running fine (as expected). Configuring NBAR-using-policy-map on an *SVI*, causes high CPU Interrupts. I do believe it's being punted to a CPU. But this time I need a document that clearly states that i.e. on SIP-200 by hardware, on SVI by software and this is not a bug/some other malfunctioning. I'm asking for a document from which we can understand that, yes, using NBAR on an SVI will make those packets punted. Technically I agree with you completely, most likely that¹s what happening. http://www.cisco.com/en/US/docs/routers/7600/ios/15S/configuration/guide/q o s.html says The PFC does not support Network-Based Application Recognition (NBAR)., this is valid for earlier SW releases as well. So your config on the SVI is not supported. SIP200 Datasheets clearly state NBAR support. oli ___ 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] advertise best-external
I know I mentioned this one on the list earlier But I just want to put the rumors to the rest once and forever So is it alright to configure the advertise best-external on all PEs under the vpnv4 address-family? Or do I need to be worried about some weird loop voodoo? And thus advertise best-external is supposed to be configured only per VRF and only on the PE with the secondary link for the particular VRF to avoid loops? yes, it's ok to enable it for all vrfs (i.e. within the vpnv4 address-family config). Not aware of any particular loops triggered by this. Enabling it on a per-vrf basis on the standby only wouldn't be too practical, active/standby can be as granular as per prefix, so PE-a could be standby for some prefixes and PE-b for others.. so global config for all VRFs is the practical config.. oli ___ 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] NBAR on SVI on 7600 w/ Sup720
Alex, On 22/01/2013 01:19, Alex K. nsp.li...@gmail.com wrote: Hi Pete, We're running 12.2(33)SRA6. On SIP-200 it's running fine (as expected). Configuring NBAR-using-policy-map on an *SVI*, causes high CPU Interrupts. I do believe it's being punted to a CPU. But this time I need a document that clearly states that i.e. on SIP-200 by hardware, on SVI by software and this is not a bug/some other malfunctioning. I'm asking for a document from which we can understand that, yes, using NBAR on an SVI will make those packets punted. Technically I agree with you completely, most likely that¹s what happening. http://www.cisco.com/en/US/docs/routers/7600/ios/15S/configuration/guide/qo s.html says The PFC does not support Network-Based Application Recognition (NBAR)., this is valid for earlier SW releases as well. So your config on the SVI is not supported. SIP200 Datasheets clearly state NBAR support. oli ___ 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] Fw: Re: ISIS P2P Behaviour with L2 Switch
Not sure but just saw some wireshark output which shows the ethernet header in ISIS is IEEE 802.3 which doesn't have ethertype field and VLAN ID is not there. ISIS uses regular 802.3 ethernet frames, so we can just insert an 802.1q tag? oli ___ 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] Difference between ISIS NSR and ISIS NSF Cisco-Style
Amit, I was testing NSR ( NSF - CIsco) in IOS-XR in GSR and CRS , However i am able to see the LSP-DB's syncing in both the routers. RP/0/8/CPU0:cr2.BLB#sh isis checkpoint lsp Tue Jan 15 05:49:21.676 IST IS-IS COLT checkpoint LSPs Level LSPID Chkpt ID 2crs1.BLB.00-00 80002c38 2cr2.BLB.00-00 80002c18 2dr2.blb-ASR1004.00-00 80002bf8 2vrr2.BLB.00-00 80002bd8 1SAR3-test7.blb.00-00 80002bb8 1crs1.BLB.00-00 80002b98 1cr2.BLB.00-00 80002b78 1pr1.BLB-7206G1.00-00 80002b58 1dr1.blb:inet.00-00 80002b38 1cng1.BLB.00-00 80002b18 1dr1.blb.00-00 80002af8 1sar4.BLB-re1.00-00 80002ad8 1sar5.BLB.00-00 80002ab8 [Š] Just to make sure LSPDB syncing is happening with NSF cisco style .Is this something newly added?? These checkpoints don't replace the database sync triggered by the PNSP, the router actually only stores the LSP header information in those checkpoints, which it uses during the sync. It's different from a full NSR solution where all LSP/LSA information would be present on the restarting RP. oli ___ 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] Link State Periodic SPF
Amit, Just a small doubt default maximumLSPGenerationInterval is 15 mins so is SPF run . If we fine tune our maximumLSPGenerationInterval to 65000 secs i.e 1083 mins , Still my ISIS SPF Periodic will be 15 mins ?? true, we don't adapt the periodic timer if you change the lsp generation timer. One might consider this a bug, but don't think it's worth fixing. I would be happy that the network is so stable that the routers actually have to perform the periodic spf runs (instead of spfs triggered by topology changes) ;-) oli ___ 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/
