09-09-2011 02:31 AM
We have a RX-16 as core router. We are trying to separate management access to the BigIron from the normal routing. The problem is that the management network can't be physically isolated from the BigIron, i.e. part of the management VLAN is switched through the BigIron.
Does anyone have an idea how to implement a management network and integrate management access to the BigIron into this network without running a physically isolated network?
Ideally we would use the management module for management. Thus that's were we started our attempts:
1. Connecting the ethernet port of the management module of the BigIron to an untagged port in the management VLAN on the BigIron, setting an management IP address on the management port. This doesn't work reliably. It seems it messes up the ARP or MAC address table of the BigIron. For instance, a ping from the BigIron to another device in the management network won't work. We see the ARP request and reply on the other side but the reply never makes it back into the BigIron (debug log doesn't show reply).
Somtimes, but not always, it's possible to ping the BigIron from a device in the management network. Then the MAC address is in the ARP table and the BigIron can communicate with the other device.
Documentation says the management network must be isolated thus maybe this approach won't work.
2. Next, we tried to separate the management network with a firewall from the main network. Again, part of the management VLAN runs through the BigIron. Again, it's not possible to use the management module port for this purpose. The problem is that it is not possible to configure a separate routing table for the management module. Even though the BigIron will route the management IP subnet to the firewall, the responses from the management module use the whole routing table of the BigIron, i.e. responses will go directly to the sender resulting in assymetric routing and the firewall blocking one-way traffic.
3. Thus, we skipped the management port and tried to set up a normal interface ip address for management. However, this isn't really feasible either. First, it's not possible to configure a non-routed IP address on an interface. Once we add an IP address on a ve interface the subnet is routed to that interface. There seems no other way to configure an IP address in a VLAN without being routed.
Which leaves as basically with ACLs or PBR, both however cumbersome to implement because it only works on the interface where traffic is incoming. That means we have to filter or policy-route all traffic on all other interfaces to prevent it from entering the management network. As we run quite a few ve's on the BigIron requiring the change then. Also this approach is not "fail-safe" as adding a new ve won't have the necessary ACL or route-map applied by default.
09-16-2011 04:44 PM
First the management port as you have found is not designed to use in any other out of band management.
So as you are already carrying you management traffic on the RX and I would assume that you have a management VLAN, You should create a VE in the management VLAN create the ACL you need there. See example below.
The following is an example of configuring BigIron RX to perform hardware filtering for Telnet access.
BigIron RX(config)# vlan 3 by port
BigIron RX(config-vlan-3)# untagged ethe 3/1 to 3/5
BigIron RX(config-vlan-3)# router-interface ve 3
BigIron RX(config-vlan-3)# exit
BigIron RX(config)# interface ve 3
BigIron RX(config-ve-1)# ip address 10.10.11.1 255.255.255.0
BigIron RX(config-ve-1)# exit
BigIron RX(config)# access-list 10 permit host 10.10.11.254
BigIron RX(config)# access-list 10 permit host 192.168.2.254
BigIron RX(config)# access-list 10 permit host 192.168.12.254
BigIron RX(config)# access-list 10 permit host 220.127.116.11
BigIron RX(config)# access-list 10 deny any
BigIron RX(config)# telnet access-group 10 vlan 3
BigIron RX(config)# ssh access-group 10 vlan 3
BigIron RX(config)# web access-group 10 vlan 3
BigIron RX(config)# snmp-server community private rw 10 vlan 3
BigIron RX(config)# access-list 25 deny host 18.104.22.168 log
BigIron RX(config)# access-list 25 deny 22.214.171.124 0.0.0.255 log
BigIron RX(config)# access-list 25 deny 126.96.36.199 0.0.0.255 log
BigIron RX(config)# access-list 25 permit any
BigIron RX(config)# access-list 30 deny 188.8.131.52 0.0.0.255 log
BigIron RX(config)# access-list 30 deny 184.108.40.206/24 log
BigIron RX(config)# access-list 30 permit any
BigIron RX(config)# snmp-server community public ro 25
BigIron RX(config)# snmp-server community private rw 30
BigIron RX(config)# write memory
In this example, a Layer 3 VLAN is configured as a remote-access management VLAN and a router interface. The IP address specified for the router interface becomes the management IP address of the VLAN.
09-16-2011 10:29 PM
Thanks Michael, but that doesn't do it. Now the management network 10.10.11.0/24 is routed on the BigIron. However, the management vlan is supposed to be separated from the normal network. There is not supposed to be any routing between the normal network and the management network.
09-17-2011 12:50 AM
You need to have an IP address to manage the box, you can secure the routered VLAN by using a ACL to drop all traffic outside the vlan.
You will also wnat to specify things like (taking VLAN 10 as the management VLAN)
BigIron RX(config)# telnet server enable vlan 10
BigIron RX(config)# web-management enable vlan 10
BigIron RX(config)# snmp-server enable vlan 10
BigIron RX(config)# tftp client enable vlan 10
09-26-2011 07:13 AM
the RX-16 has an IP address on it's management board. It's a pity we cannot use that. I really wonder why the management board doesn't have a fully separated, client interface with its own separate routing table. In particular, I don't really get why the ethernet port of the management board seems to mess up the mac forwarding table making it impossible to access it even on layer 2...
The RX-16 only supports ACLs for incoming traffic, applying ACLs to prevent packets from entering the management VLAN means to apply ACLs on all other routed interfaces. And this is not fail-safe as any newly added interface won't have that ACL. And I really would like to see that no traffic is entering the management network and not only preventing responses to be routed back.
09-27-2011 12:05 AM
well you are right.... it is a pity that the Mgmt interface on the Mgmt module is not really separated from normal/inbound tables.
It is the same on FastIron SX: IP subnet of Mgmt interface is part of the local routing table of the switch; and if you have OSPF and redistribute connected configured, all your OSPF routers will know about your outband IP subnet.
But there are no packets forwarded from inbound switched ports to/from the mgmt interface.
This is how Brocade understands out of band mgmt port. :-(
I had lot of discussions on this and also a case..... it works as designed.
We kicked our out of band management because of this.