(12-07-2016 20:55)GustavoPerrotta escribió:  

(08-07-2016 21:00)DarkCrazy escribió:  

(20-02-2016 15:11)IsaacNewton escribió:  

(19-02-2016 15:06)coolerking escribió:  Claro! Perdon pero como dice IsaacNewton, rober_176 no es 14bytes la cabecera del enlace? 12 para las mac y 2 mas por el tipo/long?

En total la cabecera ethernet es de 18 bytes (prembulo + mac dest + mac orig + campo type).

Para los ejercicios de wireshark, el preambulo no los ves (y por eso son 14: mac des y orig + type)

sls

Claro, pero faltarían 4 bytes más por el CRC que es la cola que agrega la capa de Ethernet. O no?

Esto está mal para mi (en más de un sentido).

Primero, el preámbulo son 8 BYTES (7+1 delimitador de la trama), segundo, no se cuentan en el header.

El header ethernet completo (por lo que pesa 18bytes) es: 6 (mac origen) + 6 (mac destino) + 2 (ethertype) + 4 CRC = 18bytes.
Eso es lo que el Wireshark marca como 14 ya que no te muestra el CRC.

Por favor, si estoy equivocado que alguien lo marque, ya que me va a servir saberlo bien.

GustavoPerrotta me perdí, cuál sería tu pregunta?
No coincidis que en el ejercicio 3 la trama te queda de 720bits?

Lo del header que dijiste de 18 bytes está bien. Respecto a lo que aclaraste del Wireshark no sé bien qué onda pero el tema es que los 18bytes de la cabecera son justamente como decis 14+4 y los 4 en realidad son COLA, no cabecera, y por eso supongo que no se ve en el wireshark, aunque debería estar al final de la trama, luego de todos los datos de usuario/payload.

Para los ejercicios por lo que entiendo, esos 4 los tenes siempre en cuenta porque viajan por la red, así que se toma, a fines prácticos, como que el header es de 18bytes para Ethernet.

Lo único que te voy a "corregir" es lo que dijiste del Preambulo. El preambulo es 7+1 cuando hablas de 802.3, pero cuando hablas de DIX v2 (o sea Ethernet 2), son 8 bytes de preámbulo, no tenes el delimitador.
Por lo que vi en los ejercicios de trama siempre la trama es de DIX v2 porque nos encontramos con el campo tipo. Si en cambio fuera longitud, ahí sí sería 802.3. En la práctica no sé cual se usa más comunmente, el wireshark cuál te tira de las dos?
Saludos!

PD: Alguien tiene idea quien prepara el final de mañana o quien no lo prepara?

(12-07-2016 21:46)DarkCrazy escribió:  No coincidis que en el ejercicio 3 la trama te queda de 720bits?

Pensé que estaban incluyendo el preámbulo en vez del CRC en los 18. Me da 720 por mensaje tambien.

Es asi como decis => https://wiki.wireshark.org/Ethernet#Packet_format

Gente, la capa 2 es FR, no Ethernet en el ejercicio.

El mensaje va a tener: hFR + hIP + hUDP + payload + (no recuerdo si hay algo al final del FR).

(13-07-2016 13:24)lean.cavs escribió:  Gente, la capa 2 es FR, no Ethernet en el ejercicio.

El mensaje va a tener: hFR + hIP + hUDP + payload + (no recuerdo si hay algo al final del FR).

Comparto esta idea. FR es protocolo de nivel 2, por lo que reemplazaría a Ethernet. El encabezado de FR son 2b de delimitación, 2b de dirección y 2b de CRC, según entiendo.

Estimados, ¿Como andan?

Quería dejar una consulta sobre la parte teórica.

Más precisamente, la pregunta 4 donde habla acerca de la diferencia entre DCF y PCF.

Tras una busqueda por internet y sobre los apuntes, no me está quedando claro cuál es la diferencia en el mecanismo.

Encontré por ahí que PCF se usa solo en el modo infraestructura y no en ad-hoc. ¿La diferencia es el punto de Acceso como elemento?

Gracias de antemano,

Saludos a todos!,

(17-07-2016 22:49)gaston monico escribió:  Estimados, ¿Como andan?

Quería dejar una consulta sobre la parte teórica.

Más precisamente, la pregunta 4 donde habla acerca de la diferencia entre DCF y PCF.

Tras una busqueda por internet y sobre los apuntes, no me está quedando claro cuál es la diferencia en el mecanismo.

Encontré por ahí que PCF se usa solo en el modo infraestructura y no en ad-hoc. ¿La diferencia es el punto de Acceso como elemento?

Gracias de antemano,

Saludos a todos!,

Básicamente, en el DCF los dispositivos Tx sensan el medio, si está libre mandan una solicitud para transmitir (RTS, request to send), el Rx sensa el medio y si está libre responde por libre (para recibir) u ocupado (CTS, clear to sed / TxBUSY), despues lo mismo siempre sensando primero el medio, pero el Tx ya manda DATA (si mal no recuerdo) y el Rx responde con ACK (acknoledge).

En el PCF (P de accessPoint, para recordar) el Access Point es el que orquesta la comunicacion, y le va consultando a los dispositivos que tiene conectados si tienen algo para transmitr, PCF funciona sobre DCF.

DCF funciona con CSMA/CA (Carrier Sense Multiple Access/ Colition Avoidance), que basicamente es: sensar si el medio está libre, si veo que esta libre espero un tiempo DIFS (D de Dispositivo, para recordar), si durante ese tiempo sigue libre, transmite. El accessPoint espera un tiempo PIFS (P de accessPoint) que es más corto que DIFS para que tenga prioridad, si justo los dos sensan al mismo tiempo, siempre va a ganar el AP, esta es una pregunta que le gusta hacer a algunos profesores...

De yapa, CSMA/CD (D de detect) sensa, si está libre transmite... si dos lo hacen al mismo tiempo hay colision... alguno de los dispositivos lo detecta y transmite un codigo JAMING que "le avisa" a todos que es una colision y no le tienen que dar bola.. .ahi esperan un t definido por el algoritmo binario exponencial (backoff/respaldo) y despues vuelve todo a la normaldidad.

(13-07-2016 14:38)Chocolito escribió:  

(13-07-2016 13:24)lean.cavs escribió:  Gente, la capa 2 es FR, no Ethernet en el ejercicio.

El mensaje va a tener: hFR + hIP + hUDP + payload + (no recuerdo si hay algo al final del FR).

Comparto esta idea. FR es protocolo de nivel 2, por lo que reemplazaría a Ethernet. El encabezado de FR son 2b de delimitación, 2b de dirección y 2b de CRC, según entiendo.

Alguien que me corrija si estoy equivocándome (así no meto la pata en un final ), pero frame relay está basado en HDLC, por lo tanto, el PDU de frame relay queda de la siguiente manera:

-----------------------------------------------------------------------------
|| FLAGS:1B || Dir y Control:2B || Payload || CRC:4B || FLAGS:1B ||
-----------------------------------------------------------------------------

Entonces serían 8 Bytes + Payload

Por lo que terminaría siendo (Header FR + Tail FR) + Header IP + Header UDP + Payload: 8B + 20B + 8B + 44B = 80B

(21-07-2016 20:20)marsow escribió:  

(13-07-2016 14:38)Chocolito escribió:  

(13-07-2016 13:24)lean.cavs escribió:  Gente, la capa 2 es FR, no Ethernet en el ejercicio.

El mensaje va a tener: hFR + hIP + hUDP + payload + (no recuerdo si hay algo al final del FR).

Comparto esta idea. FR es protocolo de nivel 2, por lo que reemplazaría a Ethernet. El encabezado de FR son 2b de delimitación, 2b de dirección y 2b de CRC, según entiendo.

Alguien que me corrija si estoy equivocándome (así no meto la pata en un final ), pero frame relay está basado en HDLC, por lo tanto, el PDU de frame relay queda de la siguiente manera:

-----------------------------------------------------------------------------
|| FLAGS:1B || Dir y Control:2B || Payload || CRC:4B || FLAGS:1B ||
-----------------------------------------------------------------------------

Entonces serían 8 Bytes + Payload

Por lo que terminaría siendo (Header FR + Tail FR) + Header IP + Header UDP + Payload: 8B + 20B + 8B + 44B = 80B

La trama FR es 1 byte para el primer flag, 2, 3 o 4 bytes para la dirección (supongamos que tomas 2 para el ejercicio), hasta 4096 bytes para el payload (datos), generalmente es 1600, 2 bytes para el CRC o FCS (no 4), y otro byte para el último flag.
Sin embargo, en el payload encapsula una trama Ethernet si no me equivoco, por lo que tendrías que tener en cuenta la cabecera de FR y la de Ethernet.
Pero yo no creo que hayan querido complicarla tanto, para mi ignoras la cabecera FR para calcular el tamaño del paquete. Sin embargo, si alguien lo tiene más claro estaría bueno que comparta como funciona en realidad.
Saludos!
Si estoy mal por favor corrijanme que todo este tema de las WAN nunca me queda del todo claro!

(22-07-2016 19:15)DarkCrazy escribió:  

(21-07-2016 20:20)marsow escribió:  

(13-07-2016 14:38)Chocolito escribió:  

(13-07-2016 13:24)lean.cavs escribió:  Gente, la capa 2 es FR, no Ethernet en el ejercicio.

El mensaje va a tener: hFR + hIP + hUDP + payload + (no recuerdo si hay algo al final del FR).

Comparto esta idea. FR es protocolo de nivel 2, por lo que reemplazaría a Ethernet. El encabezado de FR son 2b de delimitación, 2b de dirección y 2b de CRC, según entiendo.

Alguien que me corrija si estoy equivocándome (así no meto la pata en un final ), pero frame relay está basado en HDLC, por lo tanto, el PDU de frame relay queda de la siguiente manera:

-----------------------------------------------------------------------------
|| FLAGS:1B || Dir y Control:2B || Payload || CRC:4B || FLAGS:1B ||
-----------------------------------------------------------------------------

Entonces serían 8 Bytes + Payload

Por lo que terminaría siendo (Header FR + Tail FR) + Header IP + Header UDP + Payload: 8B + 20B + 8B + 44B = 80B

La trama FR es 1 byte para el primer flag, 2, 3 o 4 bytes para la dirección (supongamos que tomas 2 para el ejercicio), hasta 4096 bytes para el payload (datos), generalmente es 1600, 2 bytes para el CRC o FCS (no 4), y otro byte para el último flag.
Sin embargo, en el payload encapsula una trama Ethernet si no me equivoco, por lo que tendrías que tener en cuenta la cabecera de FR y la de Ethernet.
Pero yo no creo que hayan querido complicarla tanto, para mi ignoras la cabecera FR para calcular el tamaño del paquete. Sin embargo, si alguien lo tiene más claro estaría bueno que comparta como funciona en realidad.
Saludos!
Si estoy mal por favor corrijanme que todo este tema de las WAN nunca me queda del todo claro!

Te estas complicando jaja... No hay Ethernet encapsulado en FR, los dos son protocolos L2, acordate que brindan servicios a las capas superiores (en este caso encapsulan un datagrama IP) y hablan entre sus mismos, FR contra FR y Eth contra Eth... No se si soy claro.

El ejercicio te habla de una red capa 2 FR (enlaces Seriales con FR), el cuadro (eran cuadros no?) que sale de ahí es: : hFR + hIP + hUDP + payload + (si hay algo FR que vaya al final)

Saludos!

lean.cavs muchas gracias por la explicación!

Aprovecho para preguntarte y ver si finalmente me queda claro este tema de las WAN. Me decis que hablan entre sus mismos, pero si yo estoy con mi PC ordinaria y mando un mensaje a otra PC de la red WAN (teniendo entonces que viajar por dicha red), la trama que sale de mi PC no es Ethernet? En qué momento y cómo se convierte a trama FR?

Y en particular otra duda, decis hFR + hIP + hUDP + payload + (si hay algo FR que vaya al final)
Cuántos bytes tomas para el hFR? Tomas los dos bytes de los flags? El campo dirección lo tomas como 2 bytes? Contas los 2 bytes de FCS (CRC) ?
Finalmente, a qué te referis cuando decis "si hay algo FR que vaya al final" ?

Espero tu respuesta (ayuda).
Desde ya muchas gracias!!

(23-07-2016 11:20)DarkCrazy escribió:  lean.cavs muchas gracias por la explicación!

Aprovecho para preguntarte y ver si finalmente me queda claro este tema de las WAN. Me decis que hablan entre sus mismos, pero si yo estoy con mi PC ordinaria y mando un mensaje a otra PC de la red WAN (teniendo entonces que viajar por dicha red), la trama que sale de mi PC no es Ethernet? En qué momento y cómo se convierte a trama FR?

Y en particular otra duda, decis hFR + hIP + hUDP + payload + (si hay algo FR que vaya al final)
Cuántos bytes tomas para el hFR? Tomas los dos bytes de los flags? El campo dirección lo tomas como 2 bytes? Contas los 2 bytes de FCS (CRC) ?
Finalmente, a qué te referis cuando decis "si hay algo FR que vaya al final" ?

Espero tu respuesta (ayuda).
Desde ya muchas gracias!!

No hay drama. El tema es que nosotros estamos acostumbrados a Eth porque es el protocolo/tecnología que se usa ahora, pero vos bien podrías tener una PC que en lugar de conectarse a la red por Ethernet se conecte por Frame Relay como en el ejercicio. +
Tambien existe la posibilidad de que vos desde tu PC Eth capa 2, hagas un ping a otra PC del otro lado del mundo y esta acceda a la red por FR u otro protocolo capa 2, incluso ATM. En este caso tu pc "hablaría" capa 3 contra la pc del otro lado del mundo por el PING/ICMP, tu PC "habla" capa 2: Eth contra tu switch o switch capa 3 de acceso y la PC del otro lado del mundo FR contra su aparato Frame Relay de acceso, no hay comunicacion nivel 2 entre ambas PC. Obviamente en algún lugar de la red tiene que haber un router que tenga una interface Eth y otra Serial/Frame Relay... Espero no haberte mareado, igualmente la materia no llega a tanto, aca hay un gráfico muy bueno que te va a ilustrar: http://docwiki.cisco.com/wiki/Frame_Rela...over_a_WAN


Respecto al tema de la trama, tire así porque no se (ni pienso hacerlo jaja) el formato de la trama FR... De todos modos, entiedo que cuando te preguntan, quieren saber el total de bytes que va a eviar por el medio físico (capa 1). Yo (tomando esto como referencia esto: http://docwiki.cisco.com/wiki/Frame_Rela...elay_Frame ) diría que tenes 3 bytes de header FR (1B flags + 2B address) + todo lo del medio (hIP (20B si no me falla la memoria) + hUDP (8B) + datos(ver ejercicio)) + 3 bytes del tail FR (2B FCS (deteccion de error) + 1B flags).

En el caso de que no quieras considerar los flags de adelante o de atras que aparentemente tiene FR, aclará en el ejercicio eso por las dudas y le restas esos 2B que puse de más.

Espero haberte esclarecido un poco.

Buenas.

Dejo mi resolución del final para comparar.

1)

Ethernet:
MAC Destino: A0 6B B4 16 C3 D4
MAC Origen: C8 B3 73 03 55 E2
Type: 08 → IPv4
Len: 00

IPv4:
Versión: 4
Hlen: 5
ToS: 00
Longitud total: 00 2B
ID: 1C 9E
Flags + offset: 40 00
TTL: 31
Protocolo: 06 → TCP
Checksum: 63 14
IP Origen: C0 00 48 03 → 192.0.72.3
IP Destino: C0 A8 01 72 → 192.168.1.114

TCP:
Puerto Origen: 00 50 → 80
Puerto Destino: CC 74 → 52340
Nro Secuencia: 2D 8D 05 DC
Nro ACK: A4 0E 23 4B
Hlen: 5
Reservado + Flags: 0 11
FIN y ACK
Window: 00 44
Checksum: 1D EA
Puntero Urgente: 00 00

a) Lo envía el servidor con IP 192.0.72.3 ya que tiene el puerto 80, el cual está reservado para HTTP.

b) Analizo el campo flags 0000 00|010001
El segmento tiene el bit FIN activo, lo que indica que el servidor indicó que la conexión debe terminar.
El próximo segmento a recibir será un ACK por parte del cliente para iniciar la finalización de conexión en TCP

c) 192.0.72.3 y 192.168.1.114
11000000.00000000.01001000.00000011
11000000.10101000.00000001.01110010
Ambos son de clase C y no comparten la Red.

2) VLSM: 172.16.0.0 /23 para tener una red de 129, una de 10 y una de 58.

Para una red de 129 host necesito 8 bits (256)
Para una de 58 necesito 6 bits (64)
Para una de 10 necesito 4 bits (16)

Analizo el 3er y 4to octeto y uso "|" para la mascara:
00000000|.00000000 --> Red de 129 host
00000001.00|000000 --> Red de 58 host
00000001.0100|0000 --> Red de 10 host

129 Host: ID Red : 172.16.0.0 /24 -- Broadcast: 172.16.0.255 -- Rango direccionable: 172.16.0.1 - 172.16.0.254
58 Host: ID Red: 172.16.1.0 /26 -- Broadcast: 172.16.1.63 -- Rango direccionable: 172.16.1.1 - 172.16.1.62
10 Host: ID Red: 172.16.1.64 / 28 -- Broadcast: 172.16.1.79 -- Rango Direccionable: 172.16.1.65 - 172.16.1.78

3) Es un ejercicio complicado porque lo toman siempre pero nunca vi una resolución correcta corregida por un docente:

Protocolo de capa 7: SNMP (44B)
Protocolo de capa 4: UDP (8B)
Protocolo de capa 3: IPv4 (20B)
Protocolo de capa 2: FR (6B)

La trama de FR se compone de: Flag (8b) + Dirección (mínimo 16b) + Datos (Puede ser 0 a 4096 Bytes) + FCS (16 bit) + Flag (8b)

Total trama = 78B = 624 bit

Total a enviar = 50 * 624 bit = 31200 = 31,2 Kb

a) Para sondear sin marcar se debe usar el valor de BC, ya que es la rafaga garantizada de enviar. Se utiliza TC = 1 segundo.
CIR = BC / TC --> BC = CIR * TC --> BC = 128 Kbps * 1 seg --> BC = 128 Kb

Frecuencia Maxima = BC / Total a enviar = 128 Kb / 31,5 Kb = 4,10 = 4 --> Se pueden sondear hasta 4 veces por segundo todos los dispositivos sin marcar tramas.

b) Para saber cuantos puedo mandar sin rechazar, debo calcular BC + BE, ya que ahí viajan marcadas pero no rechazadas. Se utiliza TC = 1 segundo

EIR = BE / TC --> BE = EIR * TC --> BE = 64 Kb

BC + BE = 192 Kb

Lo que no entiendo acá es si se quiere sondear con la misma frecuencia que en el punto anterior. De no ser así, falta un dato en la fórmula Fmax = Rafaga / Trama * Dispositivos.

En el caso de que la frecuencia sea la misma, se toma Fmax = 4 y se despeja: Dispositivos = Rafaga / (Trama * Fmax)

Dispositivos = (BC + BE) / (Trama * Fmax) --> 192 Kb / 624 b * 4 --> Dispositivos = 76,92 = 76 --> Se pueden sondear 76 dispositivos con Frecuencia = 4 sin rechazar ninguna.

c) Esta siempre la vi igual: Se puede aumentar el AR, reducir el tamaño de la trama o monitorear en intervalos de grupo

4)
DCF es el control de acceso al medio de forma distribuida, en el cual todos deben realizar un control.

• Existe la competencia para poder transmitir.
• NAV: Indica si el medio está libre para transmitir.
• Utiliza RTS / CTS.
  

PCF es el control de acceso al medio de forma puntual, en donde se intenta que no sea 100% aleatorio.

• El AP es el encargado de asignar turnos a los equipos que intentan transmitir.
• Mientras el AP esté en modo PCF, los equipos no escuchan para transmitir sino para suscribirse a la lista de dispositivos que quieren transmitir.
• El AP va preguntando a cada uno si quiere transmitir.
• Al finalizar este modo regresa a DFC.
  

5)
El protocolo de ruteo es un conjunto de reglas para poder enviar un paquete a través de una o más redes.

Vector distancia es un algoritmo que solo toma en cuenta la menor cantidad de saltos que deben realizarse mientras que Estado de enlace (Link state) toma en cuenta el delay, la confiabilidad del enlace, la distancia y la capacidad.

6)
El campo Window tiene una longitud de 16 bits e indica la cantidad de bytes que está dispuesto a recibir.

El crédito máximo es 2^16 - 1 = 65535

TCP utiliza el mecanismo de “otorgamiento de créditos” en el cual por cada confirmación ACK este valor puede incrementar.

RTO (Retransmission timeout) es el valor que se está dispuesto a esperar sin una confirmación ACK. Una vez cumplido el tiempo, se toma como que el paquete se perdió y se retransmite.

• Su valor suele ser similar al RTT (Tiempo entre estaciones) el cual implica el tiempo que tarda un mensaje en ir a destino y volver al origen.
• También se puede utilizar el RTT Max que indica el tiempo de un mensaje entre las estaciones más alejadas de una red.
• Si se utiliza un valor muy pequeño de RTO, frente a un delay, van a existir muchas retransmisiones.
• Si hay un valor muy grande RTO, frente a una pérdida, el receptor va a tardar mucho en retransmitir.
  

Saludos