1

Ive got

eth0:0 192.168.2.10 (for bgp network announce, no vlan, alias on eth0)
eth0.1 192.168.3.20 (for bgp session 1,vlan3 transport to bgp router)
eth0.2 192.168.4.30 (for bgp session 2,vlan4 transport to bgp router)

default route is given by zebra (192.168.3.1 or 192.168.4.1 -- failover)

when external ip (192.168.1.100) tries to connect to 192.168.2.10 -> answered packets goes via 192.168.3.1 (where source ip for this is 192.168.3.20). This works correct. But i want source address to be 192.168.2.10. Main problem is when asterisk is running on 192.168.2.10 and clients try to register sip from 192.168.1.100 -> answers are send from 192.168.3.20 and packages are dropped on remote side .

How to fix/solve this? or is there any other way of configuration interfaces? Main idea is to switch routing for 192.168.2.10 if one of bgp sessions goes down.

rp_filter=0 on all interfaces

If i put something like:

iptables -t nat -A POSTROUTING -d 192.168.1.0/24 -j SNAT --to-source 192.168.5.58

this doesn't work either.

All the problem is that asterisk is behind nat in this scheme. if i run it on all interfaces -> sip client connects ok on 192.168.4.30 and 192.168.3.20 ip's , but not on 192.168.2.10 one.

MealstroM
  • 1,517
  • 1
  • 17
  • 32
  • And where's loopback mentioned except the subject? – poige Aug 12 '12 at 11:38
  • «when external ip (192.168.1.100) tryes to connect to 192.168.2.10 -> answered packages goes via 192.168.3.1 (where source ip for this is 192.168.3.20).» — you're screwed with NAT, otherwise it wouldn't change IP-address. – poige Aug 12 '12 at 11:42
  • tryes → tries, packages → packets – poige Aug 12 '12 at 11:44
  • And finally I'd suggest drawing your network topology ;) – poige Aug 12 '12 at 11:45

2 Answers2

3

lo on Linux is not the same as loopback on a Cisco.

Any address assigned to lo on Linux must be used solely for the machine to send traffic to itself; the kernel will consider any packet with a source IP that matches one assigned to lo as martian and will be dropped at ingress - this is hardcoded behaviour. The kernel does incidentally also use lo for sending traffic to itself for an IP on any other interface (so for example, if eth0 has 10.0.0.1 and you ping it, a tcpdump on lo will show the echo request and reply)

For an equivalent to the Cisco style of a loopback interface, use the "dummy" kernel module - do be aware that the dummy module also acts as a sinkhole for traffic routed to it (like null0 on a Cisco) so any address you assign to it should be a /32 since obviously nothing will be on-link for a dummy interface.

Olipro
  • 3,007
  • 19
  • 18
0

Putting non-loopback addresses on the lo interface is bound to cause weirdness. I suggest that you attach 192.168.2.10 to eth0 instead.

mgorven
  • 30,615
  • 7
  • 79
  • 122