entropy charge-wall issues

  • entropy is connected to a network with mac/ip count lock for internet access

A further clarification...

Our network registration system allows for us to set a machine as "DHCP-static", which means that it will always pull the same IP number, but is configured to perform DHCP.  So we could set those vms that way, and you could simply get Johnny to replace the mac addresses whenever you reboot.

On 04/14/2015 03:20 PM, Smith, Stephen D wrote:
> That sounds like the best solution. Release and renew will only work if
> you use dhcp.
> sds
> On 4/14/15, 3:17 PM, "Gurley, James W (Bill) (Bill)" <>
> wrote:
>> Emre:
>> Here is an answer, and a partial temporary solution:
>> Johnny Jones and I do have administrative access to the registration
>> system, at least for our 'chem' domain.  So with a quick email or phone
>> call to Johnny Jones, he can change the mac addresses for those machines
>> almost instantly.  Then I guess you could just do a "release and renew"
>> for each.
>> Johnny:
>> 865-974-3145 office
>> 423-215-5220 mobile
>> On 04/14/2015 03:06 PM, Emre Brookes wrote:
>>> qemu-kvm is running the vm images
>>> rocksos has its own flavor of inner network structure, so we use
>>> native linux tools to setup the software bridge.
>>> It all works, but the linux kernel bug prevents assignment
>>> of fixed mac addresses to vm tap'ing into the bridge.
>>> Eventually, rocks os native kernel will get patched,
>>> we could try and roll a custom kernel ourselves.
>>> So how long does it take to go the the bureaucracy to
>>> de-register and reregister a mac address with an IP ?
>>> In your new regulations, what happens if a client's network card
>>> or other hardware fails and they need to replace it with a device
>>> with a new mac address?
>>> This is basically what happens every time we reboot
>>> (which is infrequent, as least has been infrequent).
>>> -E.
>>> Smith, Stephen D wrote:
>>>> What virtualization package are you using ?  Now I feel confident that
>>>> this is not a problem with the lanman port on the switch.  I would
>>>> guess
>>>> that the arp table on the router has the old mac address associated
>>>> with
>>>> the hostname¹s ip address and needs to time out. The connection should
>>>> come up by itself after the old arp entry times out. Your system needs
>>>> to
>>>> be fixed. As a result of the security audit, OIT has been instructed
>>>> to no
>>>> longer allow unregistered mac addresses on the internet. At some point
>>>> in
>>>> the future, in its present configuration, this host will not have
>>>> access
>>>> to the internet.
>>>> Steve Smith
>>>> On 4/14/15, 2:06 PM, "Gurley, James W (Bill) (Bill)" <>
>>>> wrote:
>>>>> Oh yeah...   Steve, and are
>>>>> registered as static, and NOT performing dhcp.
>>>>> On 04/14/2015 02:01 PM, Emre Brookes wrote:
>>>>>> Smith, Stephen D wrote:
>>>>>>> I do not think that is what is happening. The switch should only be
>>>>>>> keeping a count of unique addresses that it sees at one time. I have
>>>>>>> never
>>>>>>> been able to find a table of non-connected mac addresses on a cisco
>>>>>>> switch. If you schedule a reboot, please let me know and if I am
>>>>>>> available
>>>>>>> I will watch during the reboot. If you have an unscheduled reboot
>>>>>>> and
>>>>>>> you
>>>>>>> loose connection let me know. If I am not available, ask the
>>>>>>> helpdesk
>>>>>>> to
>>>>>>> have network services investigate port edb01 gigabitethernet 6/0/16
>>>>>>> and
>>>>>>> let me know that it happened again so that I can investigate. The
>>>>>>> bpduguard is set for this switch. The port will shut if it sees
>>>>>>> bridged
>>>>>>> packets. What is the hostname of this vm ?  If the mac address
>>>>>>> associated
>>>>>>> with the hostname changes, that would cause issues with the
>>>>>>> assignment
>>>>>>> of
>>>>>>> an ip address.
>>>>>> Yes, the mac associated with the host name changes each time it is
>>>>>> rebooted.
>>>>>> It can *not* be re-assigned manually, as the software bridge on the
>>>>>> VM
>>>>>> host does not
>>>>>> support this (it is a bug recognized by linux kernel developers - see
>>>>>> below).
>>>>>> We currently use VMs with varying mac addresses:
>>>>>> and have a couple of other names for future use.
>>>>>> Thanks,
>>>>>> Emre
>>>>>> My original research:
>>>>>>> There is a way to change mac addresses on interfaces dynamically,
>>>>>>> so I
>>>>>>> setup code to
>>>>>>> do this and move eth1's mac address to the bridge.
>>>>>>> But changing the mac address of the bridge interface caused it to no
>>>>>>> longer function in my sandbox.
>>>>>>> So I dug into the bridge utilities code to see if I could set the
>>>>>>> mac
>>>>>>> address when
>>>>>>> creating the bridge, but discovered the bridge is initially
>>>>>>> assigned a
>>>>>>> mac address
>>>>>>> by the linux kernel [as it is an ioctl() command and it does not
>>>>>>> take
>>>>>>> a mac address in any argument structure
>>>>>>> and I didn't find any ioctl()'s with an alternate argument for
>>>>>>> bridge
>>>>>>> controls],
>>>>>>> and the linux kernel assigned mac address for the bridge is not
>>>>>>> consistent [creating, deleting, creating results
>>>>>>> in a new bridge mac address]
>>>>>>> Now knowing the right keywords for the linux kernel data structure,
>>>>>>> I
>>>>>>> did a search and found [dated 7 Feb 2014]
>>>>>>> Which is the linux kernel network developers mailing list [as
>>>>>>> evidenced]
>>>>>>> So it turns out changing the mac address of the bridge causes it to
>>>>>>> fail and is a linux kernel bug.
>>>>>>> I don't want to patch the kernel with the above referenced patch
>>>>>>> [and
>>>>>>> it may not even be available
>>>>>>> for our kernel tree]
>>>>>>> Conclusion : We are going to have to request a complete mac address
>>>>>>> exemption to get this to work.
>>>>>>> If UTK IT needs some reasons for their files:
>>>>>>> We can not control the bridge device's mac address and this is a
>>>>>>> known
>>>>>>> linux kernel bug
>>>>> -- 
>>>>> -Bill-
>>>>> ---------------------------------------------
>>>>>      Bill Gurley, Technical Director
>>>>>      Department of Chemistry
>>>>>      Univ. of Tennessee, Knoxville
>>>>>      865-974-3145 (office)
>>>>> ---------------------------------------------
>> -- 
>> -Bill-
>> ---------------------------------------------
>>     Bill Gurley, Technical Director
>>     Department of Chemistry
>>     Univ. of Tennessee, Knoxville
>>     865-974-3145 (office)
>> ---------------------------------------------

Last modified 3 years ago Last modified on Apr 14, 2015, 4:00:50 PM