Alan C Tait

Version 5.8 (root@manlns2.streamtech.io 16:11 21-Oct-2020) This just loops: tail -f /var/log/mpd5.log Jul 16 14:40:33 manlns1 mpd: [TUK193-10] rec'd proto LCP while dead Jul 16 14:40:33 manlns1 mpd: [TUK193-8] rec'd proto LCP while dead Jul 16 14:40:34 manlns1 mpd: [TUK193-5] L2TP: call #1385603236 terminated: result=3 error=0 errmsg="" Jul 16 14:40:34 manlns1 mpd: [TUK193-5] Link: DOWN event Jul 16 14:40:34 manlns1 mpd: [TUK193-5] LCP: Close event Jul 16 14:40:34 manlns1 mpd: [TUK193-5] LCP: state...

Version 5.8 (root@manlns2.streamtech.io 16:11 21-Oct-2020) This just loops: tail -f /var/log/mpd5.log Jul 16 14:40:33 manlns1 mpd: [TUK193-10] rec'd proto LCP while dead Jul 16 14:40:33 manlns1 mpd: [TUK193-8] rec'd proto LCP while dead Jul 16 14:40:34 manlns1 mpd: [TUK193-5] L2TP: call #1385603236 terminated: result=3 error=0 errmsg="" Jul 16 14:40:34 manlns1 mpd: [TUK193-5] Link: DOWN event Jul 16 14:40:34 manlns1 mpd: [TUK193-5] LCP: Close event Jul 16 14:40:34 manlns1 mpd: [TUK193-5] LCP: state...

startup: #set debug 1 set global l2tplimit 1 set global max-children 10000 set global qthreshold 64 1024 set global l2tpsessidletimeout 180 set global l2tpsessreplytimeout 180 #log +ALL -EVENTS -FRAME RADIUS2 -ECHO log +RADIUS5 # # Default configuration is "dialup" default: # inbound bundle configuration load LTEbundles # configure our peers, this is done before the inbound so we # always have a configured destination load l2tppeers # load one for each of the IP addresses we have on the box load...

Hello, on one LNS we keep seeing cannot assign address to ng1: file exists. This is because it is trying to repeatedly assign the template /32 from the initial bundle config and is ignoring the "framed-ip-address" attribute coming back from radius. Has anyone seen this behaviour before? From what we can see in pcap Radius is responding correctly and this is working correctly on 6 other MPD instances. it appears the radius response is being disregarded and the LNS is using a default tunnnel config....

Hello, on one LNS we keep seeing cannot assign address to ng1: file exists. This is because it is trying to repeatedly assign the template /32 from the initial bundle config and is ignoring the "framed-ip-address" attribute coming back from radius. Has anyone seen this behaviour before? From what we can see in pcap Radius is responding correctly and this is working correctly on 6 other MPD instances. it appears the radius response is being disregarded and the LNS is using a default tunnnel config....

sorry for the delayed response, we aren't seeing any major spikes in CPU load and we've added metrics to check if its any specfic hosts on the network side that are routinely causing drops it does appear to be specfic MPD related and is happening on 4 servers in different DCs with different radius servers. We've moved some network links so now we are peering more directly with the carrier core network as well. We see this in the log which is odd Oct 12 10:48:24 manlns2 kernel: ifa_maintain_loopback_route:...

quite a few, I'll pull some info together, we've been tracking this in grafana

sorry thats only on the forwarder, on a standard one we are still just getting Oct 8 08:10:45 lonlns2 mpd: L2TP: reply timeout in state wait-connect Oct 8 08:11:07 lonlns2 mpd: L2TP: reply timeout in state wait-connect Oct 8 08:16:27 lonlns2 mpd: L2TP: reply timeout in state wait-connect Oct 8 08:16:34 lonlns2 mpd: L2TP: reply timeout in state wait-connect