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

I'm doing some labs with Quagga on Ubuntu 10.04 LTS as a BGP router in a multihomed and multi router setup. Currently I have setup a fake "ISP" router in my lab and have my two Quagga routers behind it sharing routes with iBGP and I have ran into some issues that I can't seem to find a answer to.

My network setup looks like this .

R1 and R2 is connected with a link network (172.26.0.0/30) and are both connected to the same shared subnet of 172.26.1.0/24. The link network and shared subnet are on different VLANs.

R1 and R2 will be connected to one ISP each and will announce 172.26.0.0/23 to their ISP peers. It will be internaly subneted but to avoid beeing filtered a larger subnet will be announced.

The routers will have a floating IP that they share between themselfs (if one router goes down the other should take over) using uCARP.

Now to my problem. If I issue traceroute or ping from ISP1 to ip 172.26.1.1 everything goes smoothly and I get reply. If I do the same to ip 172.26.1.2 I get Request timeout.

I see the ICMP echo request on the router that have 172.26.1.2 assing to it's interface but it's like it don't know where to send the reply.

I have tried to Google for an answer but have come up empty handed. Tried a few solutions but nothing seems to work.

Is there any fault in my network design? I know that if I use the same subnet as shared subnet and linknet everything works fine except that machines behind the routers get a ICMP Redirect message when using ping and I think that is not a good implementation.

What I think happens is that the traffic destined for 172.26.1.2 is directed thru VLAN15 interface on R1 and when R2 (that has 172.26.1.2 assigned to it) it don't uses routing to get to ISP1 ip that are sending the ICMP Echo Request.

I can reach every network from each router (for example I can reach ISP1 192.168.0.1 interface) but not if I use 172.26.1.2 as source on R2. On R1 I can use 172.26.1.1 as source without any trouble.

IP Plan for routers.

ISP1

  • eth0 = 192.168.0.1
  • eth1 = 10.10.0.1

R1

  • eth0 = 10.10.0.2
  • eth1.10 = 172.26.0.1 (This is a VLAN interface for segmentation of LAN)
  • eth1.15 = 172.26.1.1 (Also VLAN interface)

R2

  • eth1.10 = 172.26.0.2 (VLAN Interface)
  • eth1.15 = 172.26.1.2 (VLAN interface)

My Quagga BGPd conf looks like this: ISP1 router bgp 65414 bgp router-id 192.168.0.1 network 192.168.0.0/23 network 10.10.0.0/24 neighbor 10.10.0.2 remote-as 65515 neighbor 10.10.0.2 description R1

R1 router bgp 64515 bgp router-id 172.26.0.1 network 172.26.0.0/23 neighbor 172.26.0.2 remote-as 65515 neighbor 172.26.0.2 description R2 neighbor 172.26.0.2 next-hop-self neighbor 10.10.0.1 remote-as 65514 neighbor 10.10.0.1 description ISP1 neighbor 10.10.0.1 prefix-list isp1_filter_out out

ip prefix-list isp1_filter_out seq 5 permit 172.26.0.0/23 ip prefix-list isp1_filter_out seq 999 deny 0.0.0.0/0 ge 1

R2 router bgp 65515 bgp router-id 172.26.0.2 network 172.26.0.0/23 neighbor 172.26.0.1 remote-as 65515 neighbor 172.26.0.1 description R2 neighbor 172.26.0.1 next-hop-self

Any thought? Is the issue in Linux or Quagga? Do you need anything more from me regarding my setup?

share|improve this question
    
What is the 'floating ip' mechanism? Is this HSRP-like using 172.16.1.100 as the shared virtual IP, and 1.1 on R1 and 1.2 on R2? I also don't understand where VLAN15 on R1 came in. Please edit the question so that each router's interfaces, ports, and subnets are listed in a simple (tabular) format. –  Aaron Dec 8 '11 at 18:56
    
Will be using uCARP for floating IP. Also I have updated the original question with your requests. –  Andreas Falck Dec 9 '11 at 7:46

1 Answer 1

up vote 0 down vote accepted

Just wanted to inform that I got some help from the Quagga-users mailing list in solving this and that this issue is resolved now.

For future reference I think that it's a good idea that I post the solution if anyone else encounters the same issue as I did.

The issue was with Ubuntu having net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter set to enabled by default. This was preventing packets from entering on one interface and leaving on another.

The suggestion in Ubuntu Bugs report (see link below) is that rp_filter is disabled when installed Quagga but this is not yet implemented.

Quagga-users mailinglist thread
Ubuntu Bugs report

share|improve this answer

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.