RE: (PM) PM3 not dead-ending routes upon discon.

James Courtier-Dutton (dutton@livingston-ent.co.uk)
Thu, 29 Apr 1999 20:42:54 +0100

Hello
PMs will be implementing a "ICMP unreachable message for pool addresses" in
the not to distant future, but until then you will have to do as described
below. It will appear for the PM4 first for obvious reasons.
Cheers
james

> -----Original Message-----
> From: owner-portmaster-users@livingston.com
> [mailto:owner-portmaster-users@livingston.com]On Behalf Of Christian
> Schmit
> Sent: Thursday, April 29, 1999 08:12
> To: Michael Bryan
> Cc: portmaster-users@livingston.com
> Subject: Re: (PM) PM3 not dead-ending routes upon discon.
>
>
> Hi,
>
> I also would appreciate to see a real solution
> here from Lucent. You have to setup different filters
> on all portmasters so that a filter only covers
> the ip pool range of the portmaster that filter is
> installed on.
>
> Christian
>
> At 12:18 AM 4/29/99 , you wrote:
> >
> >Rick Kunze wrote:
> >>
> >>[...] What is happening, is that if
> >>the dial-up user drops connection, the PM3 forwards the inbound
> stream to
> >>the main router which in turn, forwards it back to the PM3 and
> so on, till
> >>it runs out of lives so to speak.
> >>
> >>Should not the PM3 show the IP address as not available? If I ping an
> >>address in the PM3 pool (one that is NOT currently in use) from
> within my
> >>network I get an "Expired in transit" reply from the IP address
> of the PM3
> >>itself!
> >>
> >>Is this correct?
> >
> >
> >This has been discussed before, check the list archives. Some
> representative
> >articles are:
> >
> > http://www.livingston.com/tech/archive/portmaster-users/9802/1459.html
> > http://www.livingston.com/tech/archive/portmaster-users/9801/1481.html
> >
> >Bottom line --- quite a few people have complained about it, but so far
> >Lucent (and Livingston before them) has shown no interest in changing
> >this behaviour in ComOS. Instead, their answer is that you should
> >create a filter on the ethernet port so that outbound traffic is
> >dropped if the destination is an address within your assigned pool.
> >As a simple example, if you have an assigned address of 192.168.1.128,
> >and a pool size of 48, you could do the following:
> >
> > add filter ether.out
> >
> > set filter ether.out 1 deny 0.0.0.0/0 192.168.1.128/27
> > set filter ether.out 2 deny 0.0.0.0/0 192.168.1.160/28
> > set filter ether.out 3 permit 0.0.0.0/0 0.0.0.0/0
> >
> > set ether0 ofilter ether.out
> >
> > save all
> >
> >Rule 1 stops bounced packets for the first 32 addresses
> >in the pool, rule 2 stops bounced packets for the next 16.
> >If you have other filtering needs for the ethernet interface,
> >you could incorporate the above into that filter.
> >
> >
> >I still think Lucent should change ComOS so that it returns
> >an appropriate ICMP message when this happens. This issue
> >comes up on a regular basis, and although it -can- be worked
> >around with an appropriate filter, there are obviously a lot
> >of people who don't know about this until they notice it
> >causing problems and investigate it.
> >
> >What is the best/preferred way to officially request a ComOS
> >RFE from Lucent?
> >
> >
> >Michael Bryan
> >pmu@ursine.com
> >
> >-
> >To unsubscribe, email 'majordomo@livingston.com' with
> >'unsubscribe portmaster-users' in the body of the message.
> >Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
> >
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
> Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>
>

-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>