SLAAC issue in VIRL - RAs passing through shutdown interface

[Anthony L]

Hi All

I'm experiencing an odd issue with SLAAC in VIRL where an interface set to configure itself with a global unicast address via SLAAC is still able to do so despite the only router interface by which it could 'learn' an advertised prefix being in the shutdown state

• R3's Gi0/1 interface is set to configure itself with a global unicast address via SLAAC

interface GigabitEthernet0/1

      description Link to SW2

   ip address 10.12.1.2 255.255.255.0

   no ip route-cache

   ipv6 address autoconfig default

   no cdp enable

• R2's Gi0/2 interface is deliberately in the shutdown state to try to replicate the issue of stateless auto configuration not working as a result of a peer interface being in the shutdown state
• Despite R2's Gi0/2 interface being in a shutdown state, R2's Gi0/1 interface is nevertheless configuring itself with a global unicast address and more bizarre is that this is based on the prefix of R1's Gi0/1 interface

I can't seem to work out why this is. If R1 is advertising its 2001:DB8:0:10::/64 prefix, how are these router advertisements able to get past R2's Gi0/2 interface (which is shutdown) and over to R3?

The situation remains the same if, in addition to the shutdown command on R2s Gi0/2 interface, I also right-click the connector on that interface in VM Maestro's active canvas select Disable Interface (no difference after then disabling and re-enabling R3's Gi0/1 interface).

I've attached the VIRL file - would be interested in seeing if anyone else gets the same issue - or if I'm missing something!

[Harold Ritter · Accepted solution]

Hi Anthony,

In VIRL, all the management ports are connected to the same subnet. The issue is that SW1 receives the Router Advertisement (RA) message from R1 via port GI0/1. Port Gi0/1 is bridged with the management port Gi0/0 (both part of vlan1), which connects to the management port Gi0/0 on SW2. SW2 in turn bridges port Gi0/0 with Gi0/2 (both part of vlan1), which connects to Gi0/1 on R3, hence R3 receiving the RA from Gi0/1 on R1. If you want to avoid this, shutdown one of the management ports (Gi0/0) on either SW1 or SW2 or make sure that SW1 and SW2 do not bridge the management port (which is up by default on IOSL2) with the other ports.

Regards,

[Anthony L]

Hi Harold

Thanks for coming back to me.

I had a feeling it might be due to the VIRL management ports.
I've just retested my lab with Gi0/0 shutdown on SW1 and that does indeed give me the behaviour I'd expect to see in the real world : no SLAAC-configured IPv6 address on R3's Gi0/1. It's stopped me from going mad and I'm pleased I can progress with the lab now!

I'm still very much learning VIRL and don't quite understand the management ports. Some posts I've read about them mention they are important to how VIRL communicates with things in the background and to leave alone - but if I did this obviously wouldn't allow me to make VIRL behave as expected in the real-world. Do I need to bear anything in mind with shutting down management ports for future lab work - i.e. to not break anything in VIRL?

Also, you mention an alternative to shutting down one of the management ports on SW1 or SW2: "making sure SW1 and SW2 does not bridge the management port". I don't know what that means or the steps to do that. Would be grateful if you can advise. Is that a better solution to shutting down one of the ports?

Lastly, I see the router image (IOSv) has the Gi0/0 shutdown by default, whereas the switch image (IOSvL) has Gi0/0 enabled by default. Just wondering if there is a reason for this?

[Harold Ritter · Accepted solution]

Hi Anthony,

I'm glad I could help.

> Do I need to bear anything in mind with shutting down management ports for future lab work - i.e. to not break anything > in VIRL?

No. Management ports are just that, management ports. I barely use them myself. But if you want to use them, make sure they are not configured with the same vlan as the other non-management ports.

> Also, you mention an alternative to shutting down one of the management ports on SW1 or SW2: "making sure SW1 and > SW2 does not bridge the management port". I don't know what that means or the steps to do that. Would be grateful if

> you can advise. Is that a better solution to shutting down one of the ports?

Well, by default in IOSvL2, all the ports are configured as part of vlan 1. I think it would be better to shut it down or if you want to use it, you should configure the management port as a L3 port (no switchport) and assign an ip address via DHCP as follow;

interface GigabitEthernet0/0
no switchport
ip address dhcp

> Lastly, I see the router image (IOSv) has the Gi0/0 shutdown by default, whereas the switch image (IOSvL) has Gi0/0

> enabled by default. Just wondering if there is a reason for this?

You are right. The default is different for IOSv and IOSvL2. I am not sure why. I personally think this port should not be up by default in IOSvL2 either. May be I should file a feature request.

Regards,

[Anthony L]

Thanks very much Harold. That's helped me a lot and no doubt saved me a lot of potential head-scratching when I'm wondering where RAs are coming from! 

Nice to know there are a few options there too and don't necessarily need to  disable management ports (just put in different vlan or make L3 port as you say).  

[Harold Ritter]

Glad I could help Anthony.

> Nice to know there are a few options there too and don't necessarily need to disable management ports (just put in different vlan or make L3 port as you say). 

Sorry for misleading you a bit, but I think that since it is a management port, the best solution is definitely to make it a L3 ports.

Regards,

[Anthony L]

Okay L3 ports it is then. Regards the interface config for the L3 ports, where will they pick up DHCP address from? Will I need to configure a DHCP pool on a node within VIRL, or will leases be automatically served to them from outside of VIRL somehow?

If it helps, I'm running VIRL on VMware workstation.