Have a read of the info below and i would be interested in any suggestions:
i am working on a network with 1nt pdc and 5 bdc's. 1 of the bdc's is connected via a cisco2620 over an isdn line and the amount of traffic created by the pdc is keeping the line up for long periods of time. we have therefore had to temporarily switch to manual control of the line. i do not want to alter the settings on the pdc (sam database updates etc) as this will impact on the remaining bdc's.how can i limit the amount of traffic sent across the link while at the same time ensuring that updates are periodically sent to the remote bdc? i have to ensure the ip of the server is reachable for replication reasons.
does anyone have any ideas or has anyone seen any appropriate tech notes?
The ISDN link is a DDR link & will come up based on interesting traffic...now I understand that there is actually enough traffic generated all the time to bring up the link....again amount of traffic generated is decided by the pdc (bdc) & the 2620 has no control over it but then what is interesting traffic (to bring up the link or keep it up) out of that can be controlled by the 2600 (configurable parameter).
Since ISDN uses 2 B-channels, we can control when to bring up both b-channels so that all the traffic is sent across over a higher bandwidth (this is useful if we have burst of update traffic & then period of lull).
Another approach is using time-based DDR, maybe that will help in your setup since you want to send periodic updates.
this looks like this could be the approach i am looking for.
i currently have the server listed in the interesting traffic portion of my config.
however i need to make sure that the notes database residing on the pdc can replicate as and when requested but that all the other background nt services can only bring up the line during a set time period. i dont know whether this approach will block all traffic from the pdc address.
Is there a difference in the type of traffic (udp/ tcp/port number etc etc) that is generated ..... for that needs to be replicated as & when versus the nt background services updates? If yes, then the access list for interesting traffic can take care of that.
I have been looking into this, and as far as i can tell lotus domino server only uses port 1352. Does anyone know any different?
the choice is then this:
1 > block all traffic during a set period of time except domino on port 1352. this would obviously only allow domino to bring the line up but it could cause problems if i have blocked other essential ports for periods of time.
2>find out exactly which ports the pdc brings up for admin purposes and block these specific ports for a period of time.
i think i prefer the second approach as it doesnt seem as drastic and offers easier troubleshooting. the only problem i am having now is to confirm exactly which ports i should be blocking out. i have the list below and i thought i could block these for say the vast majority of the day and then allow the traffic to pass through using the time-based ddr mentionned above.
possible ports to temp block :
dns, po53 udp
rpc, po135 tcp
netbios datagrams po138 udp
netbios datagrams po139 tcp
what others should i be considering and does anyone think this situation would work ?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...