Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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 Answers 2

up vote 0 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
there is no difference. Ok. ive attached them on eth0:0 and eth0:1 aliases. Problem is the same. –  MealstroM Jul 26 '12 at 7:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.