inline
Stefano
> -Original Message-
> From: Marc-Andre Giroux [mailto:[EMAIL PROTECTED]]
> Sent: lunedl 14 maggio 2001 14.19
> To: [EMAIL PROTECTED]
> Subject: Juniper technical question [7:4398]
>
>
> 2 questions the first is what is the equivalent of a "show run" in the
> Junos worl
Hi,
until 12.0.5T the codec G729r8 was pre-IETF standard, from 12.0.5T the codec
was standardized and the 2 codec are incompatible (different bit ordering)
you must use the command "codec g729r8 pre-ietf" for interoperability but
there are some negotiation problem (rink back tone for example).
Hi,
until 12.0.5T the codec G729r8 was pre-IETF standard, from 12.0.5T the codec
was standardized and the 2 codec are incompatible (different bit ordering)
you must use the command "codec g729r8 pre-ietf" for interoperability but
there are some negotiation problem (rink back tone for example).
FRF.12 must be supported on both ends.
One side make the fragmentation and the other end must be able to reassemble
the original packet.
You can do fragmentation only from one side but both must support FRF.12 to
work properly.
So the answer is you can trun on fragmentation on one side but it mu
take a look at
http://www.cisco.com/warp/public/788/signalling/21.html
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/voice
/4712voic.htm#xtocid221719
Stefano
> -Original Message-
> From: Rodgers Moore [mailto:[EMAIL PROTECTED]]
> Sent: martedì 14 novembre 200
i had a similar problem with a cat 5500 the problem was a encapsulation
mismatch on a trunk. Correct the mismatch and the messagge go away (but for
me wasn't occasionally but every 5 seconds)
hope this help
Stefano
> -Original Message-
> From: alex campbell [mailto:[EMAIL PROTECTED]]
>
from
http://www.isi.edu/in-notes/iana/assignments/protocol-numbers
PROTOCOL NUMBERS
In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,
called "Protocol", to identify the next level protocol. This is an 8
bit field. In Internet Protocol version 6 (IPv6) [RFC1883] this field
i
-----Original Message-
> From: Bosio Stefano [mailto:[EMAIL PROTECTED]]
> Sent: giovedì 31 agosto 2000 9.57
> To: 'Jairo Nuvan'; '[EMAIL PROTECTED]'
> Subject: RE: Practicing DLSw
>
>
> PING reachability is an IP problem and is not related with
>
xcess-burst-size]]" are related to
traffic-shape rate bit-rate [burst-size [excess-burst-size]]
and is Generic Traffic Shaping not Frame-Relay Traffic Shaping.
Stefano
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: mercoledì 30 agosto 200
Deffered packet is normal on a CSMA/CD network like ethernet.
When packet must be trasmitted out on a ethernet interface the carrier are
sensed if it is busy the interface wait to send (deffer), the deffered
packet counter are incremented by 1, after a random time the interface
recheck for carrie
PING reachability is an IP problem and is not related with DLSw, try disable
DLSw config and see that nothing change.
if you have reachability between Lo i think tha problem is in PC, check for
address and default gateway
PC0 must be 10.10.66.2 and 10.10.66.1 attached on R0-Eth1 segment
PC5 must
comment inline
Stefano
>Original Message-
>From: myccie Lian [mailto:[EMAIL PROTECTED]]
>Sent: mercoledì 30 agosto 2000 7.22
>To: [EMAIL PROTECTED]
>Subject: Help on Frame-relay Traffic-shaping command
>
>
>Hi,
>I have studied following command at cisco website but I still have problem
1)
The first one
> SOMETAROU#sh conf
> Using 1961 out of 126968 bytes
> !
> version 11.2
> no service password-encryption
.
is the configuration of RSM module (internal router)
the second one
> sometarou> (enable) sh conf
> .
> ..
> ..
> ..
>
> begin
> set password $
13 matches
Mail list logo
