Hi experts, See the diagram below, it shows my scenario and the NAT behaviour I'm trying to accomplish on ASA 9.x. Hopefully it is possible! Background I'm hoping you can clarify my understanding around ASA 9.x NAT behaviour and egress interface selection. As I understand it, any twice-NAT rule will override a route-lookup and send the translated packet on its way out the mapped interface. So if you have dual-ISPs and a pair of NAT rules like below, the second one will never get hit. nat (dmz,isp1) after-auto source dynamic host1 interface nat (dmz,isp2) after-auto source dynamic host1 interface Similar behaviour seems to occur for egress traffic based on a pair of unidirectional static NAT entries, like below. The egress traffic from host1 to www will always be redirected to the isp1 interface by the NAT engine. In fact, ASDM doesn't allow the following rules to both be active at the same time - I'm not sure why in this case. nat (isp1,dmz) source static www www destination static interface isp1 host1 service SIP-5060 unidirectional nat (isp2,dmz) source static www www destination static interface isp2 host2 service SIP-5060 unidirectional So I'm wondering what the proper method is to represent hosts as different public IPs depending on which ISP the traffic flows through? Can anyone provide a sample config that matches all the desired behaviours in the diagram above? Thanks in advance. ... View more

I'm having difficulty getting same-subnet wifi multicast (SSDP) to work on a multi-vlan AIR-AP1232AG. I have two wifi stations associated to the same SSID on the same autonomous AP. The topology is: Station1 / Station2 ))) AP --trunk-- L2 Switch --trunk-- Router The router can see appropriate IGMP memberships from both stations. I've run a packet capture on the AP>Switch interface and multicast packets are making it from the wireless to the wired infrastructure just fine. Further - the stations can ping multicast listeners on the wired infrastucture - eg. Router will respond to Station1 pinging 224.0.0.2. If I put one of the wifi stations on the guest SSID then multicast between the two stations works fine. When I was running this AP as single SSID / single bridge-group (with slightly different configs), same-subnet multicast worked fine. Can anyone point me in the right direction? TIA. Platform details Station1 = LG TV Station2 = Android Mobile AP = AIR-AP1232AG IOS 12.3(8)JED1 L2 Switch = NME-16ES-1G-P IOS 12.2(58)SE2 Router = 2821 IOS 15.1(4)M6 ... View more

I have been testing a L2TPv3 pseudowire setup for implementation as a layer 2 vpn solution over an Ethernet / IP backbone. My network hardware doesn't support MPLS so we have chosen to go with L2TPv3. In the test environment I have managed to get the two Customer-Edge (CE) devices communicating with each other at layer 2 across the IP backbone. As part of the testing process I ran a packet sniffer at different points in the CE and Provider (P) networks. From this I have discovered that L2TPv3-encapsulated packets are being spammed in one direction on the data channel without any apparent reason. This traffic appears to be generated at one of the Provider-Edge (PE) routers but I have been unable to determine the cause. Control channel messages are behaving normally. The following image is a diagram of the test setup: And the next shows the wireshark locations and numbers: I have also attached the following in hopes that you might assist me in discovering the root cause of this issue: - Wireshark feeds for each point in the path in both directions (in .pcap and .txt format) - Configuration files for each device in the test case Wireshark feed ws6 shows the spammed traffic (it is of the direction PE2 > PE1). Please note that the Wireshark captures were taken over a 70 second period and in each case begun and concluded with 5 ICMP echo requests from a CE switch with datagram size set to 1400. Happy to provide further information or alternative file formats. Thanks in advance for your assistance. Message was edited by: Michael Honeyman Moved to a different community. Also - the order of the spammed encapsulated traffic on the wire seems to go 98 bytes, 106 bytes, 102 bytes. ... View more