[c-nsp] PPPoE and HTTP Redirect
Hello all, I’m looking for some recommendations. I have a customer, an ISP, who is doing PPPoE for residential and “some” smaller business accounts. PPPoE terminated on an ASR9010, DaloRadius for authentication and IP assignments. DaloRadius is configured for static IP per customer. All that is working fine. Recently, we enabled HTTP redirect on the 9010 because the customer wanted to try out a walled garden for past due accounts. So, past due accounts are handed a static 10.x.x.x IP, and password changed. Next time customer re-auth’s, they get the 10.x IP because of the bad pass, and put into the HTTP redirect jail, and are supposed to be redirected to a http site. “Sometimes” http redirect works, sometimes it doesn’t. It seems as though it depends on the destination address the end user is trying to go to. At any rate, the ISP is wanting to investigate something else for PPPoE and their walled garden. Has anyone used anything else successfully for PPPoE auth, and walled garden jail? Something that is a bit more seamless? The ISP has their own home-brewed billing/account software, and just wants a redirect to their landing page to work each time when a customer is disconnected for non-pay. I have not done a lot with PPPoE myself, so reaching out for possible 3rd party solutions that can do all-in-one. 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/
Re: [c-nsp] EOBC0/0 ifInErrors
02.10.2020 15:22, Nick Hilliard wrote: > Gert Doering wrote on 02/10/2020 09:16: >> Well, if the now-active RSP is the one with the faulty EOBC link, >> this is what would happen - by removing the standby RSP, you removed >> a lot of traffic on the EOBC bus (session sync etc). > > i.e. next step: re-insert the standby rsp, fail over to it and see what > happens. Thank you all, I'll try next week. ___ 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] EOBC0/0 ifInErrors
Gert Doering wrote on 02/10/2020 09:16: Well, if the now-active RSP is the one with the faulty EOBC link, this is what would happen - by removing the standby RSP, you removed a lot of traffic on the EOBC bus (session sync etc). i.e. next step: re-insert the standby rsp, fail over to it and see what happens. Nick ___ 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] EOBC0/0 ifInErrors
Hi, On Fri, Oct 02, 2020 at 03:00:05PM +0700, Eugene Grosbein wrote: > Instead, error rate decreased significantly but not ceased (12:25 was the > moment): > http://www.grosbein.net/cisco/eobc0_0-day.png Well, if the now-active RSP is the one with the faulty EOBC link, this is what would happen - by removing the standby RSP, you removed a lot of traffic on the EOBC bus (session sync etc). Some traffic remains (talking to the line cards), so it's not "gone" but "less" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
02.10.2020 15:00, Eugene Grosbein wrote: You have dual supervisor on this box. Can you do a failover to the secondary and see if that stops the input errors? This will localise the problem >>> >>> Do I need to disable NSF (non-stop forwarding) to localise the problem? >>> I guess both RSP should exchange data routinely when NSF is enabled. >> >> Or I could just eject stand-by RSP out of the chassis. > > So I've changed redundancy mode to to RPR (Route Processor Redundancy, was > SSO) then stand-by RSP was ejected physically. > I expected that errors would stop or would not change at all but neither > happened. > > Instead, error rate decreased significantly but not ceased (12:25 was the > moment): > http://www.grosbein.net/cisco/eobc0_0-day.png > > Also something strange happened with these stats that I consider as "fabric > utilisation": > > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.1.0 = INTEGER: 25 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.1.1 = INTEGER: 37 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.2.0 = INTEGER: 6 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.2.1 = INTEGER: 5 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.3.0 = INTEGER: 8 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.3.1 = INTEGER: 1 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.4.0 = INTEGER: 4 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.4.1 = INTEGER: 4 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.5.0 = INTEGER: 0 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.6.0 = INTEGER: 0 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.1.0 = INTEGER: 7 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.1.1 = INTEGER: 12 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.2.0 = INTEGER: 13 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.2.1 = INTEGER: 18 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.3.0 = INTEGER: 13 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.3.1 = INTEGER: 13 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.4.0 = INTEGER: 7 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.4.1 = INTEGER: 11 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.5.0 = INTEGER: 0 > CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.6.0 = INTEGER: 0 > > Here are corresponding graphs. Modules 5 and 6 (RSPs) almost always show > zeroes, > graphs for modules 1 and 4 do not show any unusual but graph for modules 2 > and 3 do: > > http://www.grosbein.net/cisco/f10-day.png > http://www.grosbein.net/cisco/f11-day.png > http://www.grosbein.net/cisco/f20-day.png > http://www.grosbein.net/cisco/f21-day.png > http://www.grosbein.net/cisco/f30-day.png > http://www.grosbein.net/cisco/f31-day.png > http://www.grosbein.net/cisco/f40-day.png > http://www.grosbein.net/cisco/f41-day.png > > I get RSP and configuration back and graphs restore to previous shapes. Also I should note this router has multiple 2 or 4-port Port-channels with 1Gbps ports. Some Port-channels have members at single line card, some have members spread over multiple line cards. Maybe this is relevant. ___ 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] EOBC0/0 ifInErrors
02.10.2020 12:24, Eugene Grosbein wrote: >> 01.10.2020 17:49, Nick Hilliard wrote: >> >>> You have dual supervisor on this box. >>> Can you do a failover to the secondary and see if that stops the input >>> errors? >>> This will localise the problem >> >> Do I need to disable NSF (non-stop forwarding) to localise the problem? >> I guess both RSP should exchange data routinely when NSF is enabled. > > Or I could just eject stand-by RSP out of the chassis. So I've changed redundancy mode to to RPR (Route Processor Redundancy, was SSO) then stand-by RSP was ejected physically. I expected that errors would stop or would not change at all but neither happened. Instead, error rate decreased significantly but not ceased (12:25 was the moment): http://www.grosbein.net/cisco/eobc0_0-day.png Also something strange happened with these stats that I consider as "fabric utilisation": CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.1.0 = INTEGER: 25 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.1.1 = INTEGER: 37 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.2.0 = INTEGER: 6 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.2.1 = INTEGER: 5 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.3.0 = INTEGER: 8 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.3.1 = INTEGER: 1 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.4.0 = INTEGER: 4 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.4.1 = INTEGER: 4 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.5.0 = INTEGER: 0 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsInUtil.6.0 = INTEGER: 0 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.1.0 = INTEGER: 7 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.1.1 = INTEGER: 12 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.2.0 = INTEGER: 13 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.2.1 = INTEGER: 18 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.3.0 = INTEGER: 13 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.3.1 = INTEGER: 13 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.4.0 = INTEGER: 7 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.4.1 = INTEGER: 11 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.5.0 = INTEGER: 0 CISCO-CAT6K-CROSSBAR-MIB::cc6kxbarStatisticsOutUtil.6.0 = INTEGER: 0 Here are corresponding graphs. Modules 5 and 6 (RSPs) almost always show zeroes, graphs for modules 1 and 4 do not show any unusual but graph for modules 2 and 3 do: http://www.grosbein.net/cisco/f10-day.png http://www.grosbein.net/cisco/f11-day.png http://www.grosbein.net/cisco/f20-day.png http://www.grosbein.net/cisco/f21-day.png http://www.grosbein.net/cisco/f30-day.png http://www.grosbein.net/cisco/f31-day.png http://www.grosbein.net/cisco/f40-day.png http://www.grosbein.net/cisco/f41-day.png I get RSP and configuration back and graphs restore to previous shapes. ___ 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/
