Monday, November 26, 2018

RA leakage across VLANs

Hello everyone, I have been on this issue for a few weeks now and have leveraged our Cisco support(we use ASA firewalls) for assistance but figured it couldn't hurt to reach out to this subreddit. To make a long story short we have several IPv6 subnets in our lab environments and for sometime noticed prefixes from one subnet/VLAN were being advertised on different VLANs. After escalating with Cisco we got a Senior Engineer that helped us out tremendously. We are using SLAAC and not DHCPv6. On our ASA we have multiple subinterfaces/VLANs that have IPv6 enabled and had address autoconfig enabled. Once we disabled address autoconfig the subinterfaces stopped populating themselves with multiple global addresses and this in turn stopped advertisements of the other prefixes through the RA . This made sense to me and this seems to have solved our issue with the exception of just one VLAN.

For some reason we have one VLAN where our VMs and devices are still generating global addresses from prefixes on other VLANs. We even have a packet capture from a server that shows the local link address of one of the ASAs subinterface on a different VLAN doing its RA. For now we are suppressing RA on all subinterfaces except for two which we need working for some of our dev teams. We do need to have RA enabled on every ipv6 network in the future for SLAAC to work on devices in those VLANs.

The subinterfaces connect to our switching environment, on the switchport end it is just a trunk port allowing only VLANs we specify(they match the subinterface VLANs on the link). We even had DELL(our switch vendor) check the config and they gave the thumbs up. Though I might need to have them do debugging next time.

Has anyone heard or seen something similar to this? I have also connected a laptop to a switchport to rule out VMware virtual networking from the equation(DELL network support after analyzing our pcap tried to pass the buck to VMware). So it would be ASA< --> userstack trunkport - userstack accessport <--> laptop. Even with this the laptop was populating addresses based on prefixes from other VLANs in addition to it's own VLAN.

I have removed certain description and ipv4 information:

ASA INTERFACE - VLAN 700 is the one with the problem, VMs/devices get global addresses populated from other VLANs, in addition to its own.

interface Ethernet0/1.1

vlan 700

security-level 60

ipv6 address fd0f:f1c3:ba53:c101::1/64

ipv6 enable

ipv6 nd prefix fd0f:f1c3:ba53:c101::/64

SWITCH INTERFACE - FYI vlan 780/781 are not ipv6 enabled

spanning-tree portfast

switchport mode trunk

switchport trunk allowed vlan 700,780-781

ASA INTERFACE - used as a test to see if the prefixes listed here appear on VLAN 700, now being RA suppressed

interface Ethernet0/3.3

vlan 774

security-level 60

ipv6 address fd0f:f1c3:ba53:c105::1/64

ipv6 enable

ipv6 nd prefix fd0f:f1c3:ba53:c105::/64

ipv6 nd suppress-ra

SWITCH INTERFACE

spanning-tree portfast

switchport mode trunk

switchport trunk allowed vlan 768,772,774,776,778

ASA INTERFACE - used as a test to see if the prefixes listed here appear on VLAN 700, now being RA suppressed

interface Ethernet0/2.2

vlan 712

security-level 60

ipv6 address fd0f:f1c3:ba53:c107::1/64

ipv6 enable

ipv6 nd prefix fd0f:f1c3:ba53:c107::/64

ipv6 nd suppress-ra

SWITCH INTERFACE

spanning-tree portfast

switchport mode trunk

switchport trunk allowed vlan 712,719,764

SWITCH INTERFACE the test laptop was connected to:

spanning-tree portfast

switchport access vlan 700

Any help or thoughts are appreciated. As of right now on Friday I have a 24 hour maintenance window. I will be plugging in a laptop directly to the ASA interface holding VLAN700. I checked and the laptop has drivers capable of VLAN tagging(tested and working) so I will tag it on VLAN700 and see if global addresses from other prefixes/VLANs show up. This is something Cisco suggested to see if perhaps it is the switching setup causing a VLAN leak or something.

EDIT: Forgot to add our DELL switches are not RA guard capable.



No comments:

Post a Comment