Awesome! Thanks James/Arie - Reason we have vpdn group per lac was purely legacy.....this particular LNS has been doing this role for 10years+....when it was first setup, carrier had probably 5 LAC's, supplied us with a config example for Cisco, which had the 5 LACs as separate vpdn groups, and it has just continued to be configured that way...the old "If it aint broke, dont fix it"
Arie - re your question on what our "other" vpdn groups look like on this LNS - Each one is LAC specific: vpdn-group QL_LAC3 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname QL_LAC3 local name LNS_QL_01 lcp renegotiation always l2tp tunnel password 7 xxxxx ip mtu adjust Thanks again for your responses/help ________________________________ From: cisco-nsp <[email protected]> on behalf of James Bensley <[email protected]> Sent: Wednesday, 6 July 2016 7:15 PM To: [email protected] Subject: Re: [c-nsp] Default / catchall VPDN group for LNS Hmm, not sure why you have a VPDN group per LAC. On 6 July 2016 at 05:36, CiscoNSP List <[email protected]> wrote: > vpdn-group 1 > ! Default L2TP VPDN group > accept-dialin > protocol l2tp > virtual-template 1 > local name LNS <- Can this be "anything"? > lcp renegotiation always > l2tp tunnel password xxxx > ip mtu adjust Yeah that is basically the gist of it, as Arie said you have selection rules, more specific wins. So from this example LNS below, we have three VPDN groups, one for $WHOLESALE-PROVIDER-1, one for $WHOLESALE-PROVIDER-2 and one for $OUT_LLU. You can see in the selection summary below that incomming L2TP tunnels that connect in a specific VRF / to a specific IP / asking for a specific hostname get matched into each of the VPDN groups; vpdn-group WHOLESALER-1 description BT WBC (21CN) SWAN accept-dialin protocol l2tp virtual-template 1 session-limit 400 vpn vrf WS-1 source-ip 1.1.1.1 local name lns1-dc01 lcp renegotiation always l2tp tunnel password 7 aaaaaa ip pmtu vpdn-group WHOLESALER-2 description TTB ADSL LTS accept-dialin protocol l2tp virtual-template 2 vpn vrf WS-2 source-ip 1.1.1.2 local name lns1-dc01 lcp renegotiation always l2tp tunnel password 7 bbbbbbb ip pmtu vpdn-group OUR-LACS description TTB ADSL LTS accept-dialin protocol l2tp virtual-template 3 vpn vrf LLU source-ip 1.1.1.3 local name lns1-dc01 lcp renegotiation always l2tp tunnel password 7 ccccccc ip pmtu lns1-dc01#show vpdn group-select summary VPDN Group Vrf Remote Name Source-IP Protocol Direction WHOLESALER-1 WS1 1.1.1.1 l2tp accept-dialin WHOLESALER-2 WS2 1.1.1.2 l2tp accept-dialin OUR-LACS LLU 1.1.1.3 l2tp accept-dialin So with $WP1 we use RADIUS, in all RADIUS requests we return the sub-interface IP 1.1.1.1 so they always connect to the sub-interface with the IP 1.1.1.1 in the VRF WS1 and thus always connect to the VPDN group WHOLESALER-1. For $WP2 we have no RADIUS integration, they have it hard coded into their RADIUS servers to connect to 1.1.1.2, that sub-interface is in the WS2 VRF and so they match into the WHOLESALER-2 VPDN group, and so on. To give a view of the bigger picture. All LNS's have these VPDN groups configured, each with a sub-interface for termianting from the different sets of LACs. For $WP1 for example we return all sub-interface IPs on all LNS's in the $WS1 VRF and they round-robin across them all so we have even traffic distribution (but we can steer in RADIUS if required) and we can graph the individual VPDN group useage per LNS, and create aggregate stack graphs etc. Hope that helps. Cheers, James. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp cisco-nsp Info Page - puck.nether.net<https://puck.nether.net/mailman/listinfo/cisco-nsp> puck.nether.net To see the collection of prior postings to the list, visit the cisco-nsp Archives. Using cisco-nsp: To post a message to all the list members, send ... archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
