|
Home > Archive > alt.certification.cisco > February 2003 > At my wits end. Need some help with removing dup UDP packets
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
At my wits end. Need some help with removing dup UDP packets
|
|
| Hansang Bae 2003-02-20, 12:24 am |
| Imagine the following:
SRVR-A SRVR-B
1.1.1.1 2.2.2.2
| |
| |
| AS 1 | AS 2
FW FW
| AS 3 | AS 3
| IBGP/EIGRP |
-----------------------------
| |
rest of EIGRP network
| |
| |
RTR-X
- RTR-X is dual homed to the "network cloud" SRVR-A and SRVR-B are
sending identical UDP broadcasts - market data feeds.
- The UDP broadcasts arrives on RTR-X from 1.1.1.1 and 2.2.2.2 source.
- From RTR-X, I helper the broadcast to various segments.
Problem: I don't want to send duplicate UDP packets to remote
locations.
So how would you remove the duplicate broadcasts? The problem is that
you have to send the udp traffic from one server only. The other
server's udp packet should go to the bit bucket until the first one
dies. You can't depend on incoming interface as SRVR-A's traffic may
come in on the left link (of "rest of EIGRP network") or the right link.
Depending on routing information won't help me since I can't detect
server failures that way. Also, the server's are NT and cannot run
OSPF/RIPV2 and therefore can't send me host routes.
The problem with PBR and route-maps is that upon first successful match
clause, it bails out of the route-map sequence.
If IOS can't do it, does anyone know of a device (some type of a reverse
load balancer) that can do this?
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| Dave Phelps 2003-02-20, 1:23 am |
| Hansang, you always ask the tough questions.
I realize that srvr-a and srvr-b are on 2 separate networks, but would
they be allowed to reach each other? Since you don't have a routing
protocol available, I'm thinking of having srvr-b ping srvr-a every few
seconds or so. Then config srvr-b so that the UDP traffic is sent to
null under normal conditions. If the pings start failing, simply add a
route (calling a batch file could handle it) to srvr-b that would cause
srvr-b to route the UDP packets to the correct destination.
When the pings are successful again, run another batch file on srvr-b to
delete the correct route that was inserted.
In article <MPG.18be36af617400e9989828@news-server.nyc.rr.com>,
uonr@alp.ee.pbz says...
> Imagine the following:
>
> SRVR-A SRVR-B
> 1.1.1.1 2.2.2.2
> | |
> | |
> | AS 1 | AS 2
> FW FW
> | AS 3 | AS 3
> | IBGP/EIGRP |
> -----------------------------
> | |
> rest of EIGRP network
> | |
> | |
> RTR-X
>
>
> - RTR-X is dual homed to the "network cloud" SRVR-A and SRVR-B are
> sending identical UDP broadcasts - market data feeds.
> - The UDP broadcasts arrives on RTR-X from 1.1.1.1 and 2.2.2.2 source.
> - From RTR-X, I helper the broadcast to various segments.
>
> Problem: I don't want to send duplicate UDP packets to remote
> locations.
>
> So how would you remove the duplicate broadcasts? The problem is that
> you have to send the udp traffic from one server only. The other
> server's udp packet should go to the bit bucket until the first one
> dies. You can't depend on incoming interface as SRVR-A's traffic may
> come in on the left link (of "rest of EIGRP network") or the right link.
>
> Depending on routing information won't help me since I can't detect
> server failures that way. Also, the server's are NT and cannot run
> OSPF/RIPV2 and therefore can't send me host routes.
>
>
> The problem with PBR and route-maps is that upon first successful match
> clause, it bails out of the route-map sequence.
>
> If IOS can't do it, does anyone know of a device (some type of a reverse
> load balancer) that can do this?
>
>
--
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring
| |
| Hansang Bae 2003-02-20, 2:24 pm |
| In article <b31uvr$1gt3c8$3@ID-121509.news.dfncis.de>,
tippenring@deadspam.com says...
> Hansang, you always ask the tough questions.
>
> I realize that srvr-a and srvr-b are on 2 separate networks, but would
> they be allowed to reach each other? Since you don't have a routing
> protocol available, I'm thinking of having srvr-b ping srvr-a every few
> seconds or so. Then config srvr-b so that the UDP traffic is sent to
> null under normal conditions. If the pings start failing, simply add a
> route (calling a batch file could handle it) to srvr-b that would cause
> srvr-b to route the UDP packets to the correct destination.
>
> When the pings are successful again, run another batch file on srvr-b to
> delete the correct route that was inserted.
The problem is a) they are not reachable and b) not under my control.
But that is an idea... maybe the vendor has a back door between the two
servers. Hmmm, never thought about doing this at the server level -
since it was out of my control. May be worth looking into though.
Thanks
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| Mortimer Mouse 2003-02-26, 7:24 am |
| Hansang Bae <uonr@alp.ee.pbz> wrote in message news:<MPG.18beff7310d1b2df989829@news-server.nyc.rr.com>...
> In article <b31uvr$1gt3c8$3@ID-121509.news.dfncis.de>,
> tippenring@deadspam.com says...
> > Hansang, you always ask the tough questions.
> >
> > I realize that srvr-a and srvr-b are on 2 separate networks, but would
> > they be allowed to reach each other? Since you don't have a routing
> > protocol available, I'm thinking of having srvr-b ping srvr-a every few
> > seconds or so. Then config srvr-b so that the UDP traffic is sent to
> > null under normal conditions. If the pings start failing, simply add a
> > route (calling a batch file could handle it) to srvr-b that would cause
> > srvr-b to route the UDP packets to the correct destination.
> >
> > When the pings are successful again, run another batch file on srvr-b to
> > delete the correct route that was inserted.
>
> The problem is a) they are not reachable and b) not under my control.
> But that is an idea... maybe the vendor has a back door between the two
> servers. Hmmm, never thought about doing this at the server level -
> since it was out of my control. May be worth looking into though.
> Thanks
>
> --
>
> hsb
>
> "Somehow I imagined this experience would be more rewarding" Calvin
> *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
> ******************************
******************************
********
> Due to the volume of email that I receive, I may not not be able to
> reply to emails sent to my account. Please post a followup instead.
> ******************************
******************************
********
If you're prepared to go outside the routers to manage the traffic,
the answer is very simple and entirely under your control...
The system works by having 2 ACLs defined on rtr-x, but only one is
applied (outbound on the internal interface) at any time. One ACL
blocks the 1.1.1.1 traffic and the other blocks the 2.2.2.2 traffic -
we'll call these ACLs Block1 and Block2 respectively. Under normal
circumstances, Block2 is applied, but using an external PC looking for
the absence of traffic from 1.1.1.1, we can use snmpset (or telnet,
expect, etc.) to apply Block1 instead. The reverse happens when
traffic from 2.2.2.2 ceases.
To monitor traffic on the PC, set up two instances of tcpdump/windump
filtering on the two sources and dumping to file. I would then run a
script/batch file periodically to look for increasing size of the
relevant output file. It could find which ACL is currently applied on
rtr-x using snmpget. If this file is not growing, use snmpget to
apply the other ACL.
There are lots of things to consider, like minimising router
"thrashing" if both sources are dead. This could be done by
progressively increasing the interval between runs of the batch file
in the same way that CSS switches failover. Likewise, you would
probably want to kill off the dump log files periodically, and so
forth.
Any thoughts...
| |
| Hansang Bae 2003-02-27, 1:24 am |
| In article <b05aa881.0302260439.651f6e76@posting.google.com>,
mortimer_mouse@mailandn
ews.com says...
> If you're prepared to go outside the routers to manage the traffic,
> the answer is very simple and entirely under your control...
Looks like that's my only answer until PING based routing becomes a
reality with Cisco gear.
> The system works by having 2 ACLs defined on rtr-x, but only one is
> applied (outbound on the internal interface) at any time. One ACL
> blocks the 1.1.1.1 traffic and the other blocks the 2.2.2.2 traffic -
> we'll call these ACLs Block1 and Block2 respectively. Under normal
> circumstances, Block2 is applied, but using an external PC looking for
> the absence of traffic from 1.1.1.1, we can use snmpset (or telnet,
> expect, etc.) to apply Block1 instead. The reverse happens when
> traffic from 2.2.2.2 ceases.
[snip]
> There are lots of things to consider, like minimising router
> "thrashing" if both sources are dead. This could be done by
> progressively increasing the interval between runs of the batch file
> in the same way that CSS switches failover. Likewise, you would
> probably want to kill off the dump log files periodically, and so
> forth.
> Any thoughts...
We have a group of people whose only function in (corporate) life is to
write scripts. So I'll submit a request to get something like this
going. I would do it, but I'm so crushed right now with work that it's
not feasible.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
|
|
|
|
|