Dual ISP/ iBGP / Strange routing Problems

Unanswered Question
Jun 17th, 2008

We have 2 internet routers, each connected to a different ISP, and connected together with an ethernet trunk.

RouterA is the HSRP primary for advertised networked 1.0.0.0 and the standby for network 2.0.0.0.

RouterB is the HSRP primary for advertised networked 2.0.0.0 and the standby for network 1.0.0.0.

RouterA has an eBGP neighbor that is providing full routes, and is advertising back both 1.0.0.0 and 2.0.0.0.

RouterB also has an eBGP neighbor that is providing full routes, and is advertising back both 1.0.0.0 and 2.0.0.0.

They have an iBGP relationship with each other simply with the configuration pointing to the neighbor, and the 'next-hop-self' statement.

The strange routing seems to occur when trying to access a few sites from a network behind RouterA that take the path through RouterB. It appears 2 or 3 ASs later the traceroutes begin to time out, as if they don't know how to come back to RouterA.

The configuration seems really basic..

RouterA

int fa0/1

no ip addr

int fa0/1.699

encapsulation dot1Q 699

ip addr 1.0.0.2 255.255.255.0

stand 1 ip 1.0.0.1

stand 1 pri 150

stand 1 pree

int fa0/1.899

encapsulation dot1Q 899

ip addr 2.0.0.2 255.255.255.0

stand 2 ip 2.0.0.1

stand 2 pri 90

ip as-path access-list 1 permit ^$

ip as-path access-list 1 deny .*

router bgp 3181

no synch

network 1.0.0.0

network 2.0.0.0

neighbor 1.0.0.3 remote-as 3181

neighbor 1.0.0.3 next-hop-self

neighbor 1.0.0.3 soft-recon in

neighbor 207.50.198.113 filter-list 1 out

neighbor 207.50.198.113 soft-recon in

===============

RouterB

int fa0/1

no ip addr

int fa0/1.699

encapsulation dot1Q 699

ip addr 1.0.0.3 255.255.255.0

stand 1 ip 1.0.0.1

stand 1 pri 90

stand 1 pree

int fa0/1.899

encapsulation dot1Q 899

ip addr 2.0.0.3 255.255.255.0

stand 2 ip 2.0.0.1

stand 2 pri 150

stand 2 pre

router bgp 3181

no synch

network 1.0.0.0

network 2.0.0.0

neighbor 1.0.0.2 remote-as 3181

neighbor 1.0.0.2 next-hop-self

neighbor 1.0.0.2 soft-recon in

neighbor 65.17.171.185 remote-as 209

neighbor 65.17.171.185 soft-recon in

neighbor 65.17.171.185 filter-list 1 out

ip as-path access-list 1 permit ^$

ip as-path access-list 1 deny .*

What is missing?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
4rmorris Tue, 06/17/2008 - 17:26

Is this a new setup? Many ISPs will only accept routes sourced from AS's validated by a routing registry (RR). We use ARIN's RR to advertise our upstream peers:

http://www.arin.net/registration/route_reg/index.html

We had a similar issue until we completed routing registry information.

You can check some looking glass sites to get an idea of whether your routes are being received and the AS path different service providers are using. This may also give you some information in case you're being black holed somewhere. Try this link for a start:

http://www.nanog.org/lookingglass.html

Good luck,

Ryan Morris

jpazahanick Tue, 06/17/2008 - 17:55

This is a new setup.

Via ARIN, I noticed the 1.0.0.0 network has an OriginAS, but the 2.0.0.0 does not.

Thanks for the pointer, we'll see if that solves it.

ashok_boin Wed, 06/18/2008 - 00:53

Router A is primary router for network 1.0.0.0 for which the problem observed as per your mail.

It might be routing through Router B as Router A does not have any specific route learned through it's own eBGP neighbor for that particular destination.

And if Router B is reachable with IP address 1.0.0.2 & then Router A also should be reachable from Internet as they are on the same Ethernet network. So, apart from registry check for your network, you need to look routing logic why it's getting routed throgh Router B.

Regards...

-Ashok.

jpazahanick Wed, 04/22/2009 - 06:16

The problem was solved by removing 'no ip redirects' on the ethernet interface... Does this make sense?

Giuseppe Larosa Wed, 04/22/2009 - 06:26

Hello Jeffrey,

this allows RA to send an icmp redirect telling the host that a better router for that specific destination (RB indeed) is present in the same LAN segment.

After receving the icmp redirect the host goes directly to RB to reach destination.

So the issue was related to asymmetric routing in some way.

Hope to help

Giuseppe

jpazahanick Wed, 04/22/2009 - 06:44

Thanks Giuseppe.. So it is common to have ip redirects enabled on internet facing routers?

Actions

This Discussion