 |
Hello. Tags/attributes assigning to VLANs is possible, but the priority of this task is minor. Attributes for IP networks have much cleaner perspective to be implemented. The common workaround for your case is to create an object type named 'client' and to assign IPs and attributes to objects of that type. The VLAN id could either be assigned to an IP network or to an object (using a custom attribute). |
 |
Hi, thanks for your quick response. But your workaround is only usable, when there aren´t any other objects in this ip subnet, isn´t it? So the object "client1" has allocated i.e. 8 IP´s. But in our system (ISP) it is possible, that the customer have an IP-Subnet (/29) and there are object, which we manage. Example: 192.168.0.0 net-id 192.168.0.1 gateway 192.168.0.2 server1 managed by customer himself 192.168.0.3 server2 managed by us ... So in my racktables installation i have two object created, both managed by us: gateway + server2 In your workaround the IP 192.168.0.1 (and 192.168.0.3) would have both two allocated objects: client1 (for attribute linking) and gateway (really object) i don´t know if this workaround is usable in my case? |
|
|
Yes, it is usable for sure. It is an IP being associated to object, not a network. So your client object would have one IP address 192.168.0.2. You may also create a physical port in a client object and document the customer physical connection. The network 192.168.0.0/29 would have these IP addesses: 1: gateway object 2: client object 3: server2 object There also could be a VLAN id binded to that network. |
|
|
Thanks, now i understand the workaround better. For every IP, which isn´t bind to an in racktables created object, i create the dummy object "client" und add there the user-defined attributes (like customer-id, contract-id). For every explicit created object (i.e. managed by me) i can add the attribute anyway. But there is one more problem in my intfrastructure. the gateway-object in our customer´s subnets are mostly a backbone-devices which belongs to our internal infrastructure. the "gateway" in customer A´s and customer B´s subnet is often the same physical machine and therefore the same object ( i. e. "core-router") with ip addresses in many customer subnets. in the workaround i can´t assign these gateway-object an customer-specific attribute. Therefore it would very useful for me, to assign attributes to ip addresses them self. i will discuss the workaround in a internal meeting, which is decisive for the introduction, in a few minutes. Thanks for your quick response/help |
|
|
Sorry, I didn't get the problem. you say: > in the workaround i can´t assign these gateway-object an customer-specific attribute. If your gateway is not specific for a particular customer, why do you want to set those attributes for it? Assign customer attributes only to the customer objects. You can distinguish customer objects from your backbone equipment by naming schema and/or tags. All the objects having IPs in a network will be displayed in the network's page. |
- Anonymous
