Franks finally started blogg

Just another WordPress site

Update Debakel

So kanns gehen. Ueber die Jahre hat sich wohl irgendwo im Update Pfad ein Bug eingeschlichen. Irgendwie,tat dann nach dem letzten security- Update im Backend gar nichts mehr und ich musste die ganze WordPress- Umgebung neu aufsetzen. Diese Aktion hat mir aus irgendwelchen Gruenden die Datenbank krumm genommen.

Gluecklicherweise habe ich noch einen Export,der aber rum zickt …sonst haette die Bestandsdatenbank ja auch einfach funktionieren koennen.

Wie dem auch sei,die alten Inhalte sind nicht weg und ich versuche sie nach und nach wieder her zu stellen. Drueckt die Daumen,dann sind die alten Tips und Tricks auch bald wieder da. Neue warten schon auf euch,aber irgendwie muss ich das hier erst mal fixen.

Voellig genervt,Frank

ProCurve 7102dl Internet uplinkProCurve 7102dl Internet uplink

These days it happened that I quickly needed a device that supplied full featured internet service to a temporary installation. The COC (carrier of choice) provided an Ethernet cable with a public IP connect and some Ethernet like uplink bandwidth. Wirespeed Ethernet routing eliminated the cheap boxes and so the ProCurve Secure Router family,since it was in stock anyway,with the wirespeed 100 Mbit Routing capability and the two Ethernet ports on board was the unit of choice. On top the device is capable to provide all locally needed services like sophisticated DHCP,DNS and time service,so that no further infrastructure components needed to be placed in this temporary setup,besides switches and WLAN components,of course. A logical choice.

Given that there are some obvious configuration steps.

First configure and activate the local Ethernet interfaces.

First the internal one:
interface eth 0/1 ip address 192.168.1.1 255.255.255.0 no shutdown exit

Then the external one:

interface eth 0/2 ip address 123.456.789.2 255.255.255.248 no shutdown exit

After configuring the IP interfaces you may add a default route. Since a routing device always refers to its routing tables,the concept of a dedicated default gateway is somehow miss leading. So simply add the global default route with the global network address and mask 0.0.0.0 and 0.0.0.0. This route should point to your gateway which you may consider to be default.

ip route 0.0.0.0 0.0.0.0 123.456.789.1

Test ping to the other side of your uplink and likely you will have a connection. Try to ping from the router to anywhere in the world and as well it likely will work. Execute the same test from an internal LAN connected device and you will fail. The wide world does not know about your local LAN adresses and since they are private likely never will. So you have to translate the local network addresses to the globaly known one,a method widely known as NAT which configures as follows:

Define an extended access list that refers to your internal communication. This could be considered to be a symbolic reference naming the LAN for the later definition of the access policy.

ip access-list extended INTERNAL permit ip 192.168.1.0 0.255.255.255 192.168.1.0 0.255.255.255

Now define the extended access list,that allows your LAN to access the Internet with the any reference.

ip access-list extended INTERNET permit ip 192.168.1.0 0.255.255.255 any

As well define a policy class that allows the LAN reference to overload the Internet connection by using a dynamic NAT.

ip policy-class INTERNALwNAT allow list INTERNAL nat source list INTERNET interface eth 0/2 overload

Finally add the access policies to the applicable interfaces. This could be even a layer two interface like PPP,but in this case its the layer one/two combination of the physical Ethernet context.

interface eth 0/1 access-policy INTERNALwNAT

and

interface eth 0/2 access-policy INTERNALwNAT

Your Internet access should work by now. For convenience in the LAN distribute your setup by subsequent configuration of the local DHCP service. In this case we preserve a couple of addresses in the lower and the upper range of the network segment for static use,such as for switches and printers. The configuration context is globally for the IP DHCP- service and not within the scope of the given DHCP- pool.

ip dhcp-server excluded-address 192.168.1.1 192.168.1.10 ip dhcp-server excluded-address 192.168.1.240 192.168.1.254

Then the DHCP pool is defined for the connected network 192.168.1.0 /24 with the speaking name of localNet. The given DNS server is a hypothetical public one. The addresses are chosen from the entire subnet,if not a exclusion was defined before.

ip dhcp-server pool localNet network 192.168.1.0 255.255.255.0 domain-name localnet.de dns-server 123.456.789.111 default-router 192.168.1.1

Now you should be done and your local clients should surf happy.

k.y.p. frank

ProCurve 5400zl and SNMPv3 ProCurve 5400zl and SNMPv3

Management security is a two edged sword. On the one hand needed to create a secure environment,on the other hand difficult to handle if you like to achive the full set of functionality. Nevertheless the shift to SSH instead of telnet and the SSL encryption on https instead of http became a commodity in active component management.

Unfortunately the further use of SNMPv1/v2c enables a slighty scillfull attacker to reactivate http and telnet to gain easy access to an active device. So going for management hardening the use of the encrypted SNMPv3 should be obligatory.

The configuration is not that hard and in the current example I configured it on the ProVision based hp networking E5412zl switch. To kick off first activate SNMPv3 and disable the snmp-server with v1-v2c:

snmpv3 enable snmpv3 only snmpv3 restricted-access no snmp-server enable

During activation the user “initial”is set up and needs to be removed further down the road. This user needs passwords and an encryption scheme,where the choice between MD5 and SHA is given. Before create a user that has proper access:

snmpv3 user test auth md5 pwdtest priv pwdtestpriv

Now you may remove the initial user:

no snmpv3 user initial

After creating the user a set of access groups need to be created and a community needs to be defined,for further referrence in alarming. E.g. activate like:

snmpv3 group ManagerAuth user test sec-model ver3 snmpv3 community index net name net sec-name net.sec

Given that a test by your management system or an command line verification on a Linux system with snmp tools installed may run with a bulk walk:

snmpbulkwalk -v3 -c net -a MD5 -A net.sec -u test -x AES -X pwdtest -l AuthPriv 192.168.7.6

asuming that your switch has the IP 192.168.7.6. If you now see a full shown SNMP tree with an awfull lot of information SNMPv3 is successfully activated on your switch. For further adoption configure your monitoring service accordingly. More detailed user access right management is possible,but this is a feasible first approach.

KYP. Frank

Angezockt:Dragon Age IIAngezockt:Dragon Age II

Endlich mal wieder etwas zum spielen. Irgendwie zieht sich seit geraumer Zeit der Spielemarkt meiner bevorzugten Provenienz ziemlich hin. D

VRRP CaveatsVRRP Caveats

Two additions to the previous posting about VRRP on the ProCurve / hp-networking E3500yl.

1.) To change anything in a VRRID you need to disable the according context.

vlan 20 vrrp vrid 20 no enable

Of course after the changes you need ro enable the according VRRID again.
Make sure that by disabling the VRID in the management VLAN on the VRRP master,
you don’t make your IP move to the backup. Thats how you easily loose management access.

2.) You should consider to enable VRRP ping. Typically the virtual IP Address does not answer ping requests. With ProCurve on the master the virtual IP is the same as the physical so ping is answered. So you need to add this feature only on the backup side of your VRRP configuration.

First you need to enable the virtual IP ping feature golbally.

router vrrp virtual-ip-ping

Thereafter activate that feature for any given VRID. Remind that you find the VRRP VRID configuration in every according VLAN.

vlan 20 vrrp vrid 20 virtual-ip-ping

kyp. f.

ProCurve MSM 410 results in new firmwareProCurve MSM 410 results in new firmware

Recently tried to import a MSM 410 within my MSM 710 based ProCurve wireless environment. The unit reportet to be not supported.

A hp- ProCurve- call resulted in the advice to update firmware. The wireless controllers contain the accesspoint firmware as well,which will be pushed out by adopting an access point. The used firmware 5.3.3 did not contain any firmware for the MSM 410.

An update to v5.3.6 on the MSM 710 solved the issue and contained proper firmware.

Super GAUSuper GAU

Irgendwie beherrscht das Thema Fukuchima nun doch l

SN6000 management initialisation SN6000 management initialisation

Finaly got some confusion again,when initially configuring SN6000 H-series SAN Switches from HP. Besides there is online help available in the management guide,the idea of using the Simple SAN Connection Manager (SSCM) seems to reduce emphasis on proper command line manuals. At least most of the reference I found was referring to that.

Assuming that you don’t have a full featured installation a quick and dirty approach for small installations might help. I got the approach that SN6000 quickly approach the market since they are heavily sicounted with the P2000 SAN starter kit,offered by HP.

This offer specially attracts small installations .

Initial setup may be done with the serial cable,set to the classical 9600,8N1 konfiguration. Be aware that your text console needs to have the as classical geometry with 80×24 characters. I made the experience that otherwise the output is scrambeled heavily.

Then you should get acces,using the default credentials:

admin / password

Start Administration with:
admin start

And then initiate the entire network setup with this sequence:
set setup system

The syntax seems little bit confusing and if you stumble through the command line extension you likely get misslead. Nevertheless this command initialtes a dialogue that configures basic network connectivity. Even IPv6 and other management services as SNMP or time.

Allthough you might skip parts of the dialogue by typing q go till the end of this dialogue. There you will be asked about activation of this configuration and you should answer y.

Give proper connectivity,you should now be able to manage teh switch in a more convenient way remotely.

KYP f.

On VmWare and NetworksOn VmWare and Networks

Over and over I meet customers,complaining about ESX HA cluster configurations which occasionally shut down their entire set of virtual guests in the HA ESX farm. What happens?

If you browse through the web you find reasonable evidence that this is a common behaviour. Further research leads to the conclusion that VmWare has decided that “network isolation”is a reason to assume that a ESX host is not anymore able to provide proper service and to ensure that nothing unplanned happens,all virtual guests are shut down.

Fine so far,but how is “network isolation”identified? VmWare judges the unavailability of the default gateway within the management network as ideal indicator for the “network isolation”.

This is IMHO garbage,for a couple of reasons:Even if you have aproper configured redundant network with high availability on layer 2 with stacking,MSTP,VRRP and whatever network outages may occur for some secconds. Primarily this happens if maintenance is done at the redundant routing. Asuming a datacenter with a reasonable amount of VMs this is absolutely no reason to shut down everything.

Even why ? Typically if this incident occurs all ESX hosts indicate network isolation,but if the farm has an issue with network connectivity at all,typically no user access may happen anyway,why should ESX shut down the guests? The network issue needs to bresolved and the VMs will be accessible thereafter. And no otehr ESX node may take over. Even worse,they all shut down any virtual guest and need quite long to come back after the network is up and running again.

Even worse,specially maintenance networks are not necessarily operated at the same level of service,than production data networks,particular since they typically provide a backdoor,if production network fails. In service oriented architectures customer specific networks carry often the payload of the VMs and the real important network conections are typically entirely different from the management interface.

So “network isolation”could never be properly indicated by the management network default gateway. The only thing thants indicated by that is that this default gateway has a problem. No reason to act like assumed.

VmWare delivers at least some relief in a
knowledge base article ,which indicates that obviously not necessarily their interpretation is right.

My personal favourite feature is simply to eliminate the default behaviour to shut down virtual guests with the advanced option:
das.powerOffOnIsolation = false .

Personal advice,check network connectivity by probing the neighbor ESX hosts on the data networks and set the above parameter.

KYP,F.

Redundant Default Gateways with VRRPRedundant Default Gateways with VRRP

Here a quick how to to provide a redundant default gateway service in a hp networking E-series based network,referring to the former ProCurve product line. Therefore VRRP is similar to HSRP. Again the following concepts and codes refer to ProVision based architectures.

As so often,the value of this protocol and feature is strictly dependent on the underlying concepts. The main issue is that it does not provide a highly available hot standby routing solution. Here no two systems run with entirely the same configuration an back each other up. According to the nature of layer three switching environments it does exactly what described above,it provides redundant default gateway service.

Since the availability of a default gateway is part of a per VLAN Layer three configuration,the VRRP is configured mainly in the VLAN context and any VLANs default gateway is secured independently. So you need at least two VRRP enabled devices,participating in the same VLAN and having a proper IP adress within this VLAN. One of the two devices should be the according routing device for this VLAN with all proper connections and routes. The intended backup device does not only need to be a part of the VLAN,it as well needs all the prerequisites needed for that VLAN routing as well,means all according routes and the routing capability enabled.

The both devices need to communicate to each other within that VLAN over layer three. And to establish a proper backup routing,both need to share the same Virtual Router ID (VRRID) referring to the according VLAN.

Before that VRRP needs to be globally enabled,after applying a according premium license. To generate a license key the license specific hardware ID is needed.

licenses Hardware-ID Premium

Delivers the ID which could be used for the license activation at My ProCurve . After that install the license key with:

licenses install Premium SG3895F03L-K-TQ4XFHT-8QHPJMG-F3WK97V-WVHGJF3

Note,that this is a trashed sample license code . But doing so properly should enable your 3500yl and 5400zl series switch,to activate dynamic routing and VRRP. After that enable VRRP globally with:

router vrrp

Now you may configure the redundant routing on your switches. Ensure that your standard routing is configured properly and working before configuring the VRRP. As well make sure you configure the primary router / Master or in VRRP terms owner,first. Otherwise the backup device may assume it should fail over and duplicates the IP of the already working default gateway.

For example you might configure redundant default gateway for VLAN 10 as follows. The IP address of the VLAN 10 interface on the switch is supposed to be 192.168.10.1. The virtual redundant router IP needs always to be the same as the already installed one,on the owner switch.

vlan 10 ip address 192.168.10.1/24 vrrp vrid 10 owner virtual-ip-address 192.168.10.1/24 enable exit

Accordingly the backup device will be configured as follows:

vlan 10 ip address 192.168.10.2/24 vrrp vrid 10 backup virtual-ip-address 192.168.10.1/24 enable exit

Thats it,virtual routing should work.

Be aware that there is no need that the master instances need to be always on the same box. As well not necessarily just two devices could pair together. The criteria is that two routing enabled instances,sharing the same VRRID see each other on the same VLAN and subnet. In larger environments,by distributing routing load administratively on several boxes the ownership may be distributed back and forth to optimize performance issues.

On the other hand this might complicate the installation significantly in terms of complexity and inherits really big confusion potential.

Reg.F.

Franks finally started blogg

Categories

Archives

A sample text widget