Re: [c-nsp] Secondary VLAN deployment on Metro ETTH
Hello, Probably I do not have luck for proper audience for the questions below, whatever the case I have began to test the Private VLAN deployment, and ran into strange packet drop issue. The test topology is simple: C7606 Gi1/22 -fiber- Gi0/1 ME3400-24TS-A - Fa0/3 client PC The PVLAN is simple enough to post. 7606 running 12.2(33)SRC4: vlan 14 name test private-vlan primary private-vlan association 140 vlan 140 name test_secondary private-vlan isolated interface Vlan14 description test ip vrf forwarding ext ip address 1.1.1.1 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp private-vlan mapping 140 interface GigabitEthernet1/22 description To_testing_ME3400-24-TS switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-61,63-4094 switchport mode trunk switchport nonegotiate logging event link-status load-interval 30 no snmp trap link-status ME3400-24-TS-A running 12.2(52)SE: vlan 14 name test private-vlan primary private-vlan association 140 vlan 140 name test_secondary private-vlan isolated interface GigabitEthernet0/1 port-type nni switchport mode trunk ip dhcp snooping trust interface FastEthernet0/3 description test_secondary_vlan switchport private-vlan host-association 14 140 switchport mode private-vlan host load-interval 30 storm-control broadcast level pps 30 storm-control multicast level pps 30 ip dhcp snooping limit rate 100 Before the PVLAN is configured I have nice connectivity from the 7606 to the client PC: 7606#ping vrf ext 1.1.1.2 repeat 1000 size 1400 Type escape sequence to abort. Sending 1000, 1400-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: !! !! !! !! !! !! !! !! !! !! !! !! !! !! Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/2/12 ms However the moment I configure PVLAN (see above) I get this: 7606#ping vrf ext 1.1.1.2 repeat 1000 size 1400 Type escape sequence to abort. Sending 1000, 1400-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: .....! .!.... !.!....!!! !.!....!!! !.!...!..! !!!.!...!. !.!....!!! !.!.!.!.!. !.!.!.!.!. ....!. ..!.!.!.!. ....!. !!....!.!! !!..!....! !!!. Success rate is 92 percent (926/1000), round-trip min/avg/max = 1/2/28 ms Which is a very interesting output (besides nice ASCII art) because the packet drop is regular - 12 pings work, 13th does not, 12 pings work, 13th does not ...Thinking about it now, maybe it has to do something with the number 13 :) -pavel skovajsa On Mon, Nov 23, 2009 at 3:47 PM, Pavel Skovajsa pavel.skova...@gmail.com wrote: Hi all, I am planning to implement Secondary VLANs feature on a Metro ETTH based on ME3400+76k. I have read various docs about the best I found is on http://blog.internetworkexpert.com/2008/07/14/private-vlans-revisited/ I have couple questions/scenarios I want to doublecheck with you: 1. Anybody using VPTv3 do disseminate the PVLAN info? 2. What if there are 3rd party switches in the environment placed randomly between the ME3400? Here is my train of thought: - From the explanations in the various docs I understood that the MAC address table for *downstream traffic* is stored
Re: [c-nsp] Secondary VLAN deployment on Metro ETTH
On Wed, 25 Nov 2009 11:09:12 +0100, you wrote: Probably I do not have luck for proper audience for the questions below, whatever the case I have began to test the Private VLAN deployment, and ran into strange packet drop issue. The test topology is simple: C7606 Gi1/22 -fiber- Gi0/1 ME3400-24TS-A - Fa0/3 client PC Why do you want to run PVLAN on the 3400? UNI ports already can't talk to each other. -A ___ 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] Secondary VLAN deployment on Metro ETTH
Hi, yes that is right UNI ports can't talk to each other but only within one ME3400 switch. If you have more switches and want exactly the same switchport protected functionality on all of them, one solution is to implement PVLANs. See http://www.rfc-editor.org/internet-drafts/draft-sanjib-private-vlan-10.txt for example. In my opinion this is a nice feature, but its implementation details are too hidden from the engineer (similar as CBWFQ for example), so you can only trust that it works and don't have too much options for troubleshooting. We are forced to separate the end customers on our Metro ISP network due to an incident where one customer decided it is a good idea to start flooding nonsense into our L2 segment. PVLAN sounded like a nice solution, but given to issues below I am open to suggestions how to separatate customer on L2. -pavel On Wed, Nov 25, 2009 at 11:43 AM, Asbjorn Hojmark - Lists li...@hojmark.org wrote: On Wed, 25 Nov 2009 11:09:12 +0100, you wrote: Probably I do not have luck for proper audience for the questions below, whatever the case I have began to test the Private VLAN deployment, and ran into strange packet drop issue. The test topology is simple: C7606 Gi1/22 -fiber- Gi0/1 ME3400-24TS-A - Fa0/3 client PC Why do you want to run PVLAN on the 3400? UNI ports already can't talk to each other. -A ___ 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] Secondary VLAN deployment on Metro ETTH
On Wed, Nov 25, 2009 at 12:17 PM, Pavel Skovajsa pavel.skova...@gmail.comwrote: Hi, yes that is right UNI ports can't talk to each other but only within one ME3400 switch. If you have more switches and want exactly the same switchport protected functionality on all of them, one solution is to implement PVLANs. See http://www.rfc-editor.org/internet-drafts/draft-sanjib-private-vlan-10.txtfor example. That would not help if you have interconnection between several switches i.e ring topology. You would need to use private-vlan turnk functionality which is iirc not supported yet on Cisco 3400 to be able to isolated several vlans between switches. You can use just one private-vlan host or combination of UNI - NNI port type chain between the switches. downlink UNI, uplink NNI and to use proxy-ARP to take care of communication between the hosts. -- iso ___ 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] Secondary VLAN deployment on Metro ETTH
Hi all, I am planning to implement Secondary VLANs feature on a Metro ETTH based on ME3400+76k. I have read various docs about the best I found is on http://blog.internetworkexpert.com/2008/07/14/private-vlans-revisited/ I have couple questions/scenarios I want to doublecheck with you: 1. Anybody using VPTv3 do disseminate the PVLAN info? 2. What if there are 3rd party switches in the environment placed randomly between the ME3400? Here is my train of thought: - From the explanations in the various docs I understood that the MAC address table for *downstream traffic* is stored in primary VLAN table - The reverse upstream traffic is stored in secondary VLAN MAC table - hence it follows (not written anywhere) that in order to properly switch the traffic and not flood it, the PVLAN implementation must do lookups in JOINED primary+secondary mac address table. Now the problem might lie in having 3rd party switches placed *between* ME3400 - they have no idea about the PVLANs hence forward it according to their VLAN tables - which are are NOT joined - hence the traffic is flooded on them. -pavel skovajsa ___ 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/
