Subject: packet looping problem

From: Dan Dovolsky <[email-masked]>
Date: Thu, 13 Jan 2005 14:20:10 -0500

Gentlemen,

I have a question about packet looping problem and would be very appreciate
if anyone could help on this.

Consider please following topology

				N2 10.0.1.0/24
| N1                        |------10.0.1.3-- R3 (loopback = 10.0.2.3/32)
|----R1 --- R2--10.0.1.1----|
|     (lpbk = 10.0.2.2/32)  |------10.0.1.4-- R4 (loopback = 10.0.2.4/32)

R1 has static route 10.0.2.0/24 with nexthop to R2.
R2 has default static route 0.0.0.0/0 with nexthop to R1

From N1 someone sends packets to the address 10.0.2.5 (which is not exist on
any node). R1 sends this packet to R2, R2 checks that this address is not in
its routing table and sends packet back to R1 using default route. Packet is
bouncing between R1 and R2 until it’s TTL expired.
During this packet looping access to N2 network is almost blocked.
This situation has caused by enabled “forwarding” option of BSD IP stack. My
question is if they’re any wide implemented solutions/fixes for this
problem.

The solution comes to my mind is to check before packet forwarding the new
resolved destination MAC address and if it’s equal to the original packet
source MAC address just drop the packet. Is there any problem with that?

Thanks very much,
Dan Dovolsky.

Regards,
Dan Dovolsky.

Office: 703-847-2438
[email-masked]

---

From: Don Goodspeed <[email-masked]>
Date: Thu, 13 Jan 2005 11:52:55 -0800

Dan,

What you've described is not an OSPF issue but a native IP
issue so while some on this list might be able to answer,
I would voice that this is the wrong forum since this should
be confined to OSPF issues.

Maybe the Routing Area WG (rtgwg) would be a better place to
post this.

-don

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dan Dovolsky
Sent: Thursday, January 13, 2005 11:20 AM
To: OSPF
Subject: packet looping problem

Gentlemen,

				N2 10.0.1.0/24

Thanks very much,
Dan Dovolsky.

Regards,
Dan Dovolsky.

Office: 703-847-2438
[email-masked]

---

From: Roch Guerin <[email-masked]>
Date: Thu, 13 Jan 2005 15:09:33 -0500

Dan,

As was pointed out in another reply, this is not an OSPF specific problem.
Typically this kind of issue would be dealt with through the use of 
"discard entries" that are added to the routing table for all the active 
address ranges that the router has (see, Section 11.1, p. 111, or RFC 
2328), and one could argue that in your example 10.0.2.0/24 is in fact 
an active address range of R2. The problem here is that R1 learns about 
it through configuration and not from R2 advertising a summary route. 
But then if you are going to be using static routes, I can definitely 
come up with lots and lots of looping scenarios if they are mis-used ;-} 
In general, you'll find references to the dangers of over-lapping 
address ranges in pretty much any routing book.

Roch

---

From: Brad Bonin <[email-masked]>
Date: Thu, 13 Jan 2005 15:37:09 -0600

Dan, a quick resolution would be to not use statics on both sides:-)

Reply direct if needed... 

Brad
[email-masked]

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Dan Dovolsky
Sent: Thursday, January 13, 2005 1:20 PM
To: [email-masked]
Subject: packet looping problem

Gentlemen,

I have a question about packet looping problem and would be very appreciate if anyone could help on this.

				N2 10.0.1.0/24
| N1                        |------10.0.1.3-- R3 (loopback = 10.0.2.3/32)
|----R1 --- R2--10.0.1.1----|
|     (lpbk = 10.0.2.2/32)  |------10.0.1.4-- R4 (loopback = 
|10.0.2.4/32)

>From N1 someone sends packets to the address 10.0.2.5 (which is not 
any node). R1 sends this packet to R2, R2 checks that this address is not in its routing table and sends packet back to R1 using
default route. Packet is bouncing between R1 and R2 until it's TTL expired.
During this packet looping access to N2 network is almost blocked.
This situation has caused by enabled "forwarding" option of BSD IP stack. My question is if they're any wide implemented
solutions/fixes for this problem.

The solution comes to my mind is to check before packet forwarding the new resolved destination MAC address and if it's equal to the
original packet source MAC address just drop the packet. Is there any problem with that?

Thanks very much,
Dan Dovolsky.

Regards,
Dan Dovolsky.

Office: 703-847-2438
[email-masked]