Re: [c-nsp] 7609 ES+, WS marking behaviour
Hello Tony and thank you for the input Unfortunately I can not get rid of the Port-Channel in my setup, byt still performed the test with: physical-interface: GigE interface / switchport Logical-interface: SVI And got the same results though. I can not though understand the behaviour of ES+ regarding mls in a scenario with a box with mixed cards (ES+ WS_67xx) The output for a show mls qos queuing for an ES+ interface (in switchport) depicts the port as untrusted #sh mls qos queuing interface tenGigabitEthernet 4/1 Weighted Round-Robin Port QoS is enabled Port is untrusted Extend trust state: not trusted [COS = 0] Default COS is 0 #show tcam interface te 4/1 qos type1 ip * Global Defaults not shared -- QOS Results: A - Aggregate Policing F - Microflow Policing M - Mark T - Trust U - Untrust -- From this output does it means that the internal DSCP value assigned to the packet will be 0 and so an ip packet arriving in an ES+ cardfor a destination behind WS_67xx will have both DSCP=0 and 802.1p = 0? (from what I have seen only 802.1p = 0, DSCP is unchanged) Thanx Victor Hi Victor, Is it possible to use an ingress policy on the ES card to match the DSCP values and explicitly set the 802.1p value based on matching the corresponding DSCP ? This way you will know that it is set and not expecting it happen by the PFC/DFC as part of the egress qos on the line card. It is also possible that having a port-channel as the logical egress interface is causing some problem, have you tried it without the port-channel ? Port-channels do strange things with QoS in general. regards, Tony. On Mon, 07 Apr 2014 07:08:11 +1000, Victor Lyapunov victor.lyapunov at gmail.com https://puck.nether.net/mailman/listinfo/cisco-nsp wrote: * Have not correcty described the setup: ** (egress) Physical : Portchannel Switch port belonging to a WS_6724 card ** (egress) Logical : SVI interface (802.1q encapsulation) for L3 ** termination ** (ingress) Physical / Logical: Routed interface belonging to a ES+ card ** (no ** 802.1q encapsulation) ** We see that traffic that is forwarded through the WS card has 802.1p = 0 ** regardless of dscp value ** But If theout going interface is also in a ES+ card then the output ** 802.1p ** corresponds to the packets DSCP value ** In ES+ a L3 interface is Dscp tust, was mistaken earlier. Indeed this ** value ** is retained (we see it in the corresponding ** output packets of the WS card) but the derived 802.p =0. Need to find a ** way ** to make this derived 802.1p value to ** correspond to the packet's DSCP when the egress interface belongs to a ** WS_67xx card * ___ 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/
[c-nsp] 7609 ES+, WS marking behaviour
Hello Have a question about 7609/RSP720 platform marking operation with mixed linecard types. In the setup we are testing uplinks are implemented in ES+ while customer facing interfaces in WS cards. The egress traffic is forwarded out of the WS cards through a Port-channel interface switchport with 802.1q encapsulation (SVI interface) We would like to be able to have the 802.1p values correspond to the DSCP of the ip packets. Normally for a WS_Card the 802.1p (CoS) value is generated based on the internal DSCP value of the packets (PFC based). I am not sure what is the case when the ingress interface belongs to an ES+ card? (Is an ES+ interface considered untrusted so internal dscp = 0 always?) Currently focused on mls qos commands to solve this but no luck so far. Is this course of action a dead end? Thanks for your help ___ 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] 7609 ES+, WS marking behaviour
Have not correcty described the setup: (egress) Physical : Portchannel Switch port belonging to a WS_6724 card (egress) Logical : SVI interface (802.1q encapsulation) for L3 termination (ingress) Physical / Logical: Routed interface belonging to a ES+ card (no 802.1q encapsulation) We see that traffic that is forwarded through the WS card has 802.1p = 0 regardless of dscp value But If theout going interface is also in a ES+ card then the output 802.1p corresponds to the packets DSCP value In ES+ a L3 interface is Dscp tust, was mistaken earlier. Indeed this value is retained (we see it in the corresponding output packets of the WS card) but the derived 802.p =0. Need to find a way to make this derived 802.1p value to correspond to the packet's DSCP when the egress interface belongs to a WS_67xx card On Sun, Apr 6, 2014 at 11:43 PM, Victor Lyapunov victor.lyapu...@gmail.comwrote: Hello Have a question about 7609/RSP720 platform marking operation with mixed linecard types. In the setup we are testing uplinks are implemented in ES+ while customer facing interfaces in WS cards. The egress traffic is forwarded out of the WS cards through a Port-channel interface switchport with 802.1q encapsulation (SVI interface) We would like to be able to have the 802.1p values correspond to the DSCP of the ip packets. Normally for a WS_Card the 802.1p (CoS) value is generated based on the internal DSCP value of the packets (PFC based). I am not sure what is the case when the ingress interface belongs to an ES+ card? (Is an ES+ interface considered untrusted so internal dscp = 0 always?) Currently focused on mls qos commands to solve this but no luck so far. Is this course of action a dead end? Thanks for your help ___ 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/
[c-nsp] Tx Queue for 7609 WS67xx cards
Hello all Got a question about queuing functionality in WS67xx cards. We have a typical 7609 setup with TenG uplink and GigE downlink interfaces. During the day we see an increase in packet drops on the GigE downlink interfaces. The average bandwidth is kept around 750Mbps but I suppose short bursts may result in dropped packets. Is there any way to improve this behavior? (e.g increase output buffer?) The current state of the interfaces is following: = We have enabled mls qos for the 7609 interface GigabitEthernet1/22 description test switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1100 switchport mode trunk mtu 9216 load-interval 30 speed nonegotiate mls qos trust dscp no cdp enable GigabitEthernet 1/22 is up, line protocol is up (connected) Hardware is C7600 1Gb 802.3, address is f8687.f2da.ea01 (bia f8687.f2da.ea01) Description: test MTU 9216 bytes, BW 100 Kbit/sec, DLY 10 usec, reliability 255/255, txload 181/255, rxload 28/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of show interface counters 40d07h Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 2845472 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 110375000 bits/sec, 48500 packets/sec 30 second output rate 713714000 bits/sec, 81902 packets/sec lab7609#sh mls qos queuing interface g1/22 Weighted Round-Robin Port QoS is enabled Trust state: trust DSCP Extend trust state: not trusted [COS = 0] Default COS is 0 Queueing Mode In Tx direction: mode-cos Transmit queues [type = 1p3q8t]: Queue IdScheduling Num of thresholds - 01 WRR 08 02 WRR 08 03 WRR 08 04 Priority01 WRR bandwidth ratios: 100[queue 1] 150[queue 2] 200[queue 3] queue-limit ratios: 50[queue 1] 20[queue 2] 15[queue 3] 15[Pri Queue] queue tail-drop-thresholds -- 1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-min-thresholds -- 140[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] 240[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] 370[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] queue random-detect-max-thresholds -- 170[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 270[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] WRED disabled queues: queue thresh cos-map --- 1 1 0 1 2 1 1 3 1 4 1 5 1 6 1 7 1 8 2 1 2 2 2 3 4 2 3 2 4 2 5 2 6 2 7 2 8 3 1 6 7 3 2 3 3 3 4 3 5 3 6 3 7 3 8 4 1 5 Queueing Mode In Rx direction: mode-cos Receive queues [type = 2q8t]: Queue IdScheduling Num of thresholds - 01 WRR 08 02 WRR 08 WRR bandwidth ratios: 100[queue 1] 0[queue 2] queue-limit ratios:100[queue 1] 0[queue 2] queue tail-drop-thresholds -- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-min-thresholds -- 140[1] 40[2] 50[3] 50[4] 50[5] 50[6] 50[7] 50[8] 2100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-max-thresholds -- 170[1] 80[2] 90[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue thresh cos-map --- 1 1 0 1 2 3 4 5 6 7 1 2 1 3 1 4 1 5 1 6 1 7 1 8 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 Packets dropped on Transmit: queue dropped [cos-map]
[c-nsp] DHCP_PD usage for PPPoE Access
Hello I have been testing some scenarios for IPv6 over broadband connections. The setup is a the most common one, the CPE gets -One ::/128 WAN ipv6 address using autonegotiaton. -A signle ::/56 LAN subnet for the user networks, through DHCP-PD (further subneted into /64 subnets for the various VLANs in the CPE) For this setup the NAS server is configured with a local ipv6 pool for WAN address assignment (autonegotiation) ipv6 local pool PPPOE 2001:100::/64 128 shared And a second pool used by the DHCP_PD ipv6 local pool LAN 2001:200::/48 56 In this way I have to maintain two different pools (one for CPEs WAN and one LAN addressing). A possible alternative that is discussed, is having the NAS allocate just the DHCP_PD ::/56 prefix to the CPE (as far as global addresses are concerned). And then configure the CPE to use the first of the resulting 256 ::/64 subnets for the WAN and the rest for the LANs. What is your experience, is the second alternative worth pursuing? Is there a common practice? Thanx for the input ___ 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/
[c-nsp] 7609_uRFP Performance Impact
Hello all I am examining the prospect of enabling urfp in a cisco 7609 / RSP 720 platform, for subscriber facing interfaces. My needs are covered by plain strict urpf (no acls, or multipath support is needed). According to documentation traffic failing urpf is supposed to be handled in hardware. In my setup the mls rate-limiter for unicast ip rpf-failure is disabled (needed the rate limiter resources for other traffic types) Is the mls unicast ip rpf-failure rate limiter needed in the case of strict urfp? or its usage is limited to packets failing uRFP check when ACL / multipath is needed? Thnx ___ 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] Assigning a static IPv6 address to a PPP session
Hello Bjørn, Gert Bjørn have you tried using the Framed-Interface-Id with a Cisco CPE? I have tried the combination Framed-Interface-Id + Framed-IPv6-Prefix with no luck so far (The /64 prefix is applied to the dialer interface but the last 64 bits of the PPP interface address are not affected by the Framed-Interface-Id attribute) In the ERX which attribute do you use for defining the Prefix delegated through DHCP-PD? In the Cisco config that I have tried so far, I can statically define the IPv6 prefixes for either the Dialer (assigned through autoconfiguration) or the Ethernet Interface (assigned through DHCP-PD) Specifically if I include the no ipv6 nd prefix framed-ipv6-prefix statement in the virtual-template the prefix is advertised to the CPE through DHCP-PD. Without this command the prefix is advertised through the router-advertisements during the autoconfiguration phase and assigned to the PPP interface of the CPE I have not found the necessary commands that will enable me to assigh through radius both PPP and DHCP-PD addresses of the CPE. The config for the LNS aaa authorization configuration default group radius ipv6 dhcp pool LAN prefix-delegation aaa dns-server 163::1 domain-name ipv6.test.com interface Virtual-Template100 ip unnumbered Loopback4 ipv6 enable no ipv6 nd prefix framed-ipv6-prefix ipv6 nd other-config-flag no ipv6 nd ra suppress ipv6 dhcp server LAN peer default ip address pool v4_POOL peer default ipv6 pool PPPOE ppp authentication pap ppp ipcp dns 10.0.1.1 Config for the CPE interface Dialer100 ip address negotiated encapsulation ppp dialer pool 100 ipv6 address autoconfig default ipv6 enable ipv6 dhcp client pd LAN ppp pap sent-username user1 password 0 user1 ppp ipcp dns request ppp ipcp route default interface FastEthernet0/1 ip address 10.0.100.100 255.255.255.0 duplex auto speed auto ipv6 address LAN ::1/64 ipv6 enable ipv6 nd other-config-flag ipv6 dhcp server TEST Gert in your approach (using DHCP for both LAN and WAN interfaces of the CPE) how can have the CPE peek for the WAN, a /64 subnet from the /56 assigned through the DHCP-PD? I have tried using the command ipv6 address LAN ::2/64 in the Dialer interface but with no success. With the Cisco-AVPair = ipv6:prefix#1=2001:1::/56 the CPE tries to assign the first /64 subnet for both WAN and F0/1 interface and so an error is generated. Is there a specialI can use to force the Dialer choose the second /64 subnet of the 2001:1::/56 prefix? Thnx both for the help On Mon, Mar 15, 2010 at 9:02 PM, Bjørn Mork bj...@mork.no wrote: Gert Doering g...@greenie.muc.de writes: Does Framed-Interface-ID configure the *client* side via IPv6CP? Now that's interesting indeed. (I'm not sure we would something else than ::1 there, to ensure the CPE has a well-known and pingable address, but it's definitely a nice tool). Yes. With this RADIUS account (the prefix is statically configfured in this case): bjoer...@ipv6.online.no Cleartext-Password := verysecret Framed-Interface-Id := 0:0:0:c I get this on the client side: ipv6-pppoe-1:~# pppd nodetach debug noip call ipv6-1 Serial connection established. using channel 2 Using interface ppp0 Connect: ppp0 -- /dev/pts/0 sent [LCP ConfReq id=0x1 magic 0xea58b813 pcomp] rcvd [LCP ConfReq id=0xb2 mru 1492 auth pap magic 0x442c1e2] sent [LCP ConfAck id=0xb2 mru 1492 auth pap magic 0x442c1e2] rcvd [LCP ConfAck id=0x1 magic 0xea58b813 pcomp] sent [LCP EchoReq id=0x0 magic=0xea58b813] sent [PAP AuthReq id=0x1 user=bjoer...@ipv6.online.no password=hidden] rcvd [LCP EchoRep id=0x0 magic=0x442c1e2] rcvd [PAP AuthAck id=0x1 Nextra dialin] Remote message: Nextra dialin PAP authentication succeeded sent [CCP ConfReq id=0x1 deflate 15 deflate(old#) 15 bsd v1 15] sent [IPV6CP ConfReq id=0x1 addr fe80::5254:06ff:fe66:] rcvd [LCP ProtRej id=0x8 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Protocol-Reject for 'Compression Control Protocol' (0x80fd) received rcvd [IPV6CP ConfNak id=0x1 addr fe80:::::000c] sent [IPV6CP ConfReq id=0x2 addr fe80:::::000c] rcvd [IPV6CP ConfAck id=0x2 addr fe80:::::000c] rcvd [IPV6CP ConfReq id=0x40 addr fe80::0090:1a00:0141:70f7] sent [IPV6CP ConfAck id=0x40 addr fe80::0090:1a00:0141:70f7] local LL address fe80:::::000c remote LL address fe80::0090:1a00:0141:70f7 Script /etc/ppp/ipv6-up started (pid 1439) Script /etc/ppp/ipv6-up finished (pid 1439), status = 0x0 And the expected ::c ifid is used both on the link local and the global address: ipv6-pppoe-1:~# ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet6 addr: 2001:4600:10:11::c/64 Scope:Global inet6 addr: fe80::c/10 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1452 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0
[c-nsp] Assigning a static IPv6 address to a PPP session
Hello all I am trying to test IPv6 configuration for PPPoE / DHCP-PD termination. I have trouble assigning a static /128 IPv6 address through radius. I use the following simple config for the LNS interface Virtual-Template100 ip unnumbered Loopback4 no ipv6 nd prefix framed-ipv6-prefix ipv6 enable ipv6 nd other-config-flag no ipv6 nd ra suppress ipv6 dhcp server LAN peer default ip address pool v4_POOL peer default ipv6 pool PPPOE ppp authentication chap ppp ipcp dns 10.0.1.1 ipv6 local pool PPPOE 2001:100::/64 128 shared ipv6 local pool LAN 2001:200::/48 64 Using the Radius-Attribute Cisco-AVPair = ipv6:prefix#1=2001:1::/64 0 0 onlink autoconfig the router can statically define the prefix assigned through the DHCP-PD to the CPE I cannot find the appropriate Radius-Attribute for statically defining the IPv6 address for the CPE's PPP interface. Does anyone knows how to define through radius the IPv6 address that can assigned to a PPP user? Thanx for your help ___ 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] 7609 DHCP alternatives - EVC / Subinterfaces
Thank you all for the replies To be honest I was leaning towards the subinterfaces alternative for implementing L3 termination points for DHCP subscribers. Just to sum things up: Subinterfaces alternative: -They comsume an internal VLAN for each subintreface. -For each subsciber no mac-address table is required, just and ARP entry. EVC alternative: -Using a bridge domain only one VLAN will suffice. -But because of the bridge-domain the 7600 will have to populate its mac-address table with one entry for each subscriber. -Also since the evc-alternative is partly L2 based the dhcp-snooping security mechanisms can be employed. I am concerned about the mac-address capacity. Since servicing DHCP subscribers in ES+ is purely a L3 service there should be no need to populate the mac-table with extra entries (in this way more resources can be used for other L2 services). Victor On Sat, Oct 24, 2009 at 5:19 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Victor, Use the EVC alternative. It would allow you to get the flexibility offered by EVC with regards to VLAN number space, L2 services scalability, QOS and many other advanced capabilities. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Victor Lyapunov Sent: Tuesday, October 20, 2009 09:54 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7609 DHCP alternatives - EVC / Subinterfaces Hi All I am trying to test DHCP functionality with 7600 router. Traffic arrives from all customer facing interfaces (ES+), arrive using the same VLAN. 7600 perfoms DHCP relay and acts as a gateway for all of them. With the new cards ES+ we have two options for the configuration of customer facing interfaces 1. Using EVC + SVI interface int g4/1 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int g4/2 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int Vlan 100 ip address 10.0.0.1 255.255.255.0 ip helper address 192.168.0.1 2. Using IP subinterfaces int loopback 100 ip address 10.0.0.1 255.255.255.0 int g4/1.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 int g4/2.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 Both configurations seem to achieve the same effect but I am not sure which one is the preferable for large amount of traffic / subscribers. For example due to the bridge domain I would expect that the first alternative will create more entries in the mac-address table. Thanx Victor ___ cisco-nsp mailing list cisco-...@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/
[c-nsp] 7609 DHCP alternatives - EVC / Subinterfaces
Hi All I am trying to test DHCP functionality with 7600 router. Traffic arrives from all customer facing interfaces (ES+), arrive using the same VLAN. 7600 perfoms DHCP relay and acts as a gateway for all of them. With the new cards ES+ we have two options for the configuration of customer facing interfaces 1. Using EVC + SVI interface int g4/1 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int g4/2 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int Vlan 100 ip address 10.0.0.1 255.255.255.0 ip helper address 192.168.0.1 2. Using IP subinterfaces int loopback 100 ip address 10.0.0.1 255.255.255.0 int g4/1.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 int g4/2.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 Both configurations seem to achieve the same effect but I am not sure which one is the preferable for large amount of traffic / subscribers. For example due to the bridge domain I would expect that the first alternative will create more entries in the mac-address table. Thanx Victor ___ 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] QoS on 837 using PPPoE
Hello I agree with the others, if you have to apply QoS for an ADSL link (upstream traffic only) you must enforce some sort of queueing / shaping on a lower layer. The ATM vc that your connection uses is the just right place for this. Just that when I tried something similar I could only make CBWFQ work properly for the ADSL link if instead of vbr-nrt I used cbr for the VC. This may be dependant on the IOS version but in any case be prepared to experiment a little bit with the various QoS settings of the ATM VC. correct. vbr-nrt only affects the output not the input. regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi Siva, Your suggestions seem to have to have worked. Just so that I understand, the vbr-nrt shaping is just for the outbound cells and does not affect inbound traffic correct?? This is a 3m/384k and I do not want to affect their inbound. I could only reserve 288k in my policy (which is fine since the upload is only 384k). And the logs did show why it did not take the command and I was able to adjust my policy as the logs suggested. I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available only 288 (kbps) This is now what shows up in the config policy-map Voice class VoIP priority 288 interface ATM0.1 point-to-point pvc 1/100 vbr-nrt 384 384 encapsulation aal5snap service-policy output Voice pppoe-client dial-pool-number 1 On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan svall...@cisco.com wrote: what does the log messages say? a show log should tell you why it didn't accept the commands. On Tue, 7 Jul 2009, Clue Store wrote: It took the command under the pvc section, but after a sho run the config did not show up. Nor when I did a show policy-map interface a0.1 did anything show up. I've looked through several docs on the cisco site, but did not come up with anything that seem'd to work. Will try to upgrade the IOS later tonight. Anyone else with any ideas?? On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan svall...@cisco.com wrote: IIRC you need to apply it on the ATM interface e.g. Interface ATM0.1 point-to-point . . pvc 1/100 service-policy output Voice regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi All, I am having a hard time trying to figure how to apply a QoS policy on this router. I have applied a few typical service-policies on the dialer interfaces, but a show policy interface di0 shows packets being matched but nothing being dropped and the link is saturated. I believe the policy needs to be applied to the virtual-access interface that comes up when PPP negotiates, but i'm not quite sure how this would be done since the use of vpdn-groups are no longer used. Relevent config posted. Any suggestions are greatly appreciated. *And yes I know the service-policy is not applied to the dialer interface...this was due to it not working. class-map match-any VoIP match ip rtp 16384 16383 match access-group name VoicePorts ! ! policy-map Voice class VoIP priority 256 ! ! ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Ethernet2 no ip address shutdown hold-queue 100 out ! interface ATM0 no ip address load-interval 30 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 1/100 encapsulation aal5snap pppoe-client dial-pool-number 1 ! ! interface FastEthernet1 duplex auto speed auto ! interface FastEthernet2 duplex auto speed auto ! interface FastEthernet3 duplex auto speed auto ! interface FastEthernet4 duplex auto speed auto ! ! interface Dialer0 ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1412 dialer pool 1 no cdp enable ppp info ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 ! ip http server no ip http secure-server ! no ip nat service skinny tcp port 2000 no ip nat service sip udp port 5060 ip nat inside source list 10 interface Dialer0 overload ! ! ip access-list extended VoicePorts permit udp any host *.*.*.* range 22026 62025 permit udp any host *.*.*.* range 22026 62025 access-list 10 permit 192.168.10.0 0.0.0.255 ___ 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/
[c-nsp] Cisco router DHCP accounting / option82
Hello all I am experimenting with a 7200 router playing the role of DHCP server for xDSL subscribers. In this simple setup the 7200 is the first L3 node for the xDSL subscribers. Apart from playing the role of the default gateway, the 7200 using its local DHCP server also handles the address allocation for the users. One requirement is for the DHCP server be able to store accounting data about the bindings, especially the option82 information inserted by the DSLAM in the DHCP requiests. The DHCP accounting works (the router is able to inform a radius server when it has performed an IP allocation or release) but I have not been able to make the 7200 to also send the option82 information to the radius. (I have verified that the option82 information indeed reaches the 7200). I have experimented with various radius options (overiding nas-port-id attribute with circuit-id) but with no luck so far. Has anyone succeded in making the DHCP server of a cisco router to include the Option82 information in the accouting records it sends to a radius? ___ 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] LAC - Disable Accounting messages just for L2TP users
Hello Arie I have tried this command but without luck. The vpdn tunnel accounting network seems to controll the generation of accounting Tunnel-Start/Tunnel-Stop and Tunnel-Reject (codes 9, 10, 11) accounting type messages, not the Start and Stop (code 1 and 2). So when vpdn tunnel accounting network is enabled using radius, the LAC generates Tunnel-Start/Tunnel-Stop in addition to Start and Stop accounting messages. If vpdn tunnel accounting network is configured to null, Tunnel-Start and Tunnel-Stop are indeed suppressed but Start and Stop are still generated by the LAC. I was wondering (and trying - without success) if using the sss - subscriber-profile commands would help me Thanx for your help Victor. On Sat, Jan 24, 2009 at 9:49 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Victor, Try looking at this command:vpdn tunnel accounting network http://www.cisco.com/en/US/docs/ios/vpdn/command/reference/vpd_v1.html#w p1013076 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Victor Lyapunov Sent: Saturday, January 24, 2009 11:00 To: cisco-nsp@puck.nether.net Subject: [c-nsp] LAC - Disable Accounting messages just for L2TP users Hello all I am trying to perform some tests where a Cisco router takes up the role of a LAC, forwarding PPP calls to the appropriate LNS according to the domain name provided by the user. At the same time this LAC must be able to localy terminate PPP sessions offering internet services to subscribers. I have used a fairly simple config like the aaa group server radius SUBS server a.b.c.d auth-port 1812 acct-port 1813 throttle accounting 150 load-balance method least-outstanding ! aaa authentication ppp SUBS group SUBS aaa authorization network SUBS aaa accounting network SUBS action-type start-stop aaa accounting network default none vpdn-group l2tp-domain request-dialin protocol l2tp domain l2tp-domain initiate-to ip x.x.x.x source-ip y.y.y.y local name LAC l2tp tunnel password 0 cisco bba-group pppoe PPPOE virtual-template 10 interface Virtual-Template10 ip unnumbered Loopback0 peer default ip address pool PPP_POOL_1 ppp authentication pap SUBS ppp authorization SUBS ppp accounting SUBS The problem is that for the users that are localy terminated we need radius accounting. On the other hand no accounting is required for the L2TP forwarded users. Still the router generated accounting Start / Stop messages for these VPDN users creating extra load for the radius server. Is there a way to differentiate the accounting between VPDN and localy terminated subscribers? Specificaly disable accounting for L2TP fordwarded users and at the same time use radius accounting for localy terminated subscribers. Any help is welcomed ___ 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/
[c-nsp] LAC - Disable Accounting messages just for L2TP users
Hello all I am trying to perform some tests where a Cisco router takes up the role of a LAC, forwarding PPP calls to the appropriate LNS according to the domain name provided by the user. At the same time this LAC must be able to localy terminate PPP sessions offering internet services to subscribers. I have used a fairly simple config like the aaa group server radius SUBS server a.b.c.d auth-port 1812 acct-port 1813 throttle accounting 150 load-balance method least-outstanding ! aaa authentication ppp SUBS group SUBS aaa authorization network SUBS aaa accounting network SUBS action-type start-stop aaa accounting network default none vpdn-group l2tp-domain request-dialin protocol l2tp domain l2tp-domain initiate-to ip x.x.x.x source-ip y.y.y.y local name LAC l2tp tunnel password 0 cisco bba-group pppoe PPPOE virtual-template 10 interface Virtual-Template10 ip unnumbered Loopback0 peer default ip address pool PPP_POOL_1 ppp authentication pap SUBS ppp authorization SUBS ppp accounting SUBS The problem is that for the users that are localy terminated we need radius accounting. On the other hand no accounting is required for the L2TP forwarded users. Still the router generated accounting Start / Stop messages for these VPDN users creating extra load for the radius server. Is there a way to differentiate the accounting between VPDN and localy terminated subscribers? Specificaly disable accounting for L2TP fordwarded users and at the same time use radius accounting for localy terminated subscribers. Any help is welcomed ___ 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/
[c-nsp] ACL vs IP verify unicast: TCAM entries
Hello All At work we have a network of BRAS for PPP termination, consisting of Juniper ERX and Cisco 10k. I was wondering what is the most efficient way to filter incoming subscriber traffic. We would like to verify that incoming subscriber traffic is indeed sourced from the IP that we assigned to them. We can achieve this by either: -Creating an ACL that is common for every subscriber (same for all routers) that allows incoming traffic originating from the address ranges that are assigned to us. This would create an incoming ACL with roughly 24 entries that would be applied to the Virtual-Access interfaces. -Activating ip verify unicast in the virtual-template interface What is the mechanism employed by ip verify unicast? Does it create on-the-fly an ACL for each interface that it is applied to containg in my case just one entry that matches the network address of the interface? In this case in a typical BRAS terminating 16000 users would require 16000 dynamically created unique ACLs (or policy-lists in the ERX). Obviouly from a security perspective ip verify unicast seems to be the optimal solution but would consume more memory / CAM entries in ERX case. If our primary concern is keeping the load in the routers low, should ip verify unicast be considered the best solution? From your experience does applying an ACL with one entry creates less load that an ACL with 24? (in theory all entries should be processed in parallel) Any help is welcomed ___ 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/
