IP Helper-Address For DHCP and WDS in Different VLANs - cisco

Scenario:
Clients on VLANs X
DHCP server on VLAN Y
WDS server on VLAN Z
We have IP helper-address command on our layer 3 device for DHCP. I would like to avoid using DHCP options and instead add another IP helper-address command to point clients to WDS as well. Is this possible? I know having two IP helper-address commands will direct traffic to both IPs but will this work correctly if the WDS server is not also hosting DHCP services?

in your case, use the ip helpper to specify the dhcp server and WDS server specify using the options dhcp server (use option 66 and 67).
example dhcp server for cisco IOS:
ip dhcp pool NETWORK10.10.10.0/24
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server 10.10.10.10
option 66 ascii WDS-server.domainname.local
option 67 ascii Boot\x86\wdsnbp.com
lease 0 24
good like

Related

SMA390 RPC port not responding for public facing IP

I have been working on CISCO's SMA390 and the RPC port for the device is not responsive when connected to a core switch.
1. The core switch is for public-facing IP/ CIMC IP of the device.
2. The IP's are configured and using ipmitool command.
3. The port is responding when tried to configure over a private network(laptop to device connection).
I have tried ping command after checking that the IP's are configured and its failing while the gateway is responding.
ipmitool lan print 1
ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 10.10.1.5
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 10.10.1.1
ipmitool lan set 1 access on
ipmitool raw 0x36 0x52 0x0f
I want the ping and the ssh to be enabled.
I figured out after some more troubleshooting that CISCO x90 devices by default work on 100G bandwidth connection. The default provided on x95 devices is 1000G bandwidth connection. Hence the RPC port didn't respond.
If you face this issue, try
1. using a 100G connection.
2. change the default connection acceptance bandwidth of your device(i.e x90 here).

Send traffic to self over physical network on Ubuntu

I have a dual port ethernet NIC and let's say I have connected 2 ports in a loop and assigned the following IPs to the 2 ethernet interfaces:
eth2 -> 192.168.2.1
eth3 -> 192.168.3.1
I want to send traffic from 1 port to another over the physical network, e.g. ping 192.168.3.1 from 192.168.2.1. However, the TCP/IP stack in the Linux kernel recognizes that these two addresses are local and instead sends the traffic to the loopback adapter, so the traffic never hits the physical network.
The closest I have to a solution is Anastasov's send-to-self patch, which unfortunately, has been discontinued since kernel 3.6 so it won't work on Ubuntu 13.10 (kernel 3.11) for me. I've tried finding rewriting the patch for 3.11, but I can't seem to locate these in the Ubuntu distro:
include/linux/inetdevice.h
net/ipv4/devinet.c
net/ipv4/fib_frontend.c
net/ipv4/route.c
Documentation/networking/ip-sysctl.txt
Is there a way I can get the send-to-self patch to work, or an alternative?
You can use network namespaces for this purpose.
As ip-netns's manpage says:
A network namespace is logically another copy of the network stack,
with its own routes, firewall rules, and network devices.
Following is just a copy of this answer:
Create a network namespace and move one of interfaces into it:
ip netns add test
ip link set eth1 netns test
Start a shell in the new namespace:
ip netns exec test bash
Then proceed as if you had two machines. When finished exit the shell and delete the namespace:
ip netns del test
you can try configuring route table, by running "ip" command:
ip route add to unicast 192.168.3.1 dev eth2
ip route add to unicast 192.168.2.1 dev eth3
new route would be added into route table, and it should be able to take effect before egress routing lookup hit the host-local route between "192.168.3.1" and "192.168.2.1", therefore, the traffic should be sent through physical interface "eth2" and "eth3", instead of loopback "lo"
Never tried myself, but should work.

Send all traffic to network interface and receive from other

i'm triying to imagine how to do:
(with Linux Debian based distro)
I have PC with 4 NIC:
eth0 = Internet Access (connect to router WAN)
eth1 = Local lan
eth2 = OUT NIC
eth3 = IN NIC
I need to send all traffic from eth1 (local lan) to eth2, receive the same traffic from eth3 and route to eth0.
The idea is send all eth1 traffic to external device over eth2, the external device inspect the packets and send to PC again on eth3, then my PC Linux route traffic to eth0
Is posible to do that ?
You're running linux on a PC? We need to know the version first off. Second you are looking into IProutes if you want to redirect traffic from one NIC to another.

OpenSIPs stun module require two IP addresses

I have to make a STUN server in OpenSIPs, and it says that I need to bind 2 IP addresses.
http://www.opensips.org/About/News0042
A STUN server uses 2 ips and 2 ports to create 4 sockets on which to listen or respond.
STUN requires 2 routable ip addresses
How can I enable two public IP addresses into one Linux server? I've searched all website, and failed to find the answer.
Several options.
Option 1.
You likely just need to use ifconfig from the command line to start
You can assign an additional static IP address to your NIC via the command line. Type ifconfig to get the name of your default adapter. It's typically "eth0". Then do add a secondary address to this adapter, the command is something like the following:
sudo ifconfig eth0:1 inet up netmask 255.255.255.0 192.168.1.55
Where 255.255.255.0 is the netmask of my 8-bit subnet and 192.16.1.55 is an existing IP address that no other device on my subnet is already using.
Option 2.
After you get your server up and running with Option 1, you likely need to find a way to get the IP address assigned by "ifconfig" to persist after a reboot. You could likely stick an ifconfig statement into one of your rc.init files. But most Linux skus have a formal way of configuring an interface with another /etc file. But this step varies between different flavors of Linux. On Ubuntu, this is all defined in the /etc/network/interfaces file. Add these three lines to the bottom of your existing file:
iface eth0:1 inet static
address 192.168.1.55
netmask 255.255.255.0
Option 3 (shameless plug)
Switch to Stuntman ( www.stunprotocol.org ) as your STUN server. Its default mode only requires one IP address to be present on the box. Most client usages of the STUN protocol don't require the second IP address unless to do NAT classification and behavior tests.

How to route TCP/IP responses through a different interface?

I have two machines each with two valid network interfaces, an Ethernet interface eth0 and a tun/tap interface gr0. The goal is to start a TCP connection on machine A using interface gr0 but then have the responses (ACKs, etc) from machine B come back over the Ethernet interface, eth0. So, machine A sends out a SYN on gr0 and machine B receives the SYN on its own gr0 but then sends its SYN/ACK back through eth0. The tun/tap device is a GNU Radio wireless link and we just want the responses to come through the Ethernet.
What's the easiest way to accomplish this? I need to research more on TCP/IP, but I was initially thinking that source-spoofing outgoing packets would tell the receiver to respond to the spoofed address (which should get routed to eth0). This would involve routing the IPs from the tun/tap interfaces through gr0 and leave the other traffic to eth0.
We are using Linux and a Python solution would be preferable.
Thanks for looking!
You could add an additional address to the lo interface on each system and use these new addresses as the TCP connection endpoints. You can then use static routes to direct which path each machine takes to get to the other machine's lo address.
For example:
Machine A:
ip addr add 1.1.1.1/32 dev lo
ip route add 2.2.2.2/32 dev eth0 via <eth0 default gateway>
Machine B:
ip addr add 2.2.2.2/32 dev lo
ip route add 1.1.1.1/32 dev gr0
Then bind to 1.1.1.1 on machine A and connect to 2.2.2.2.
You may be interested in enabling logging of martian packets net.ipv4.conf.all.log_martians, and disable reverse path filtering net.ipv4.conf.<interface>.rp_filter on the affected interfaces.
This sysctl vars are accesible via the sysctl utility and/or the /proc filesystem.

Resources