J'ai besoin de votre aide pour valider mes dire afin de trouver quelle est
la taille maximale d'une trame L2TP véhiculée (entre le LAC et le LNS) sur
un réseau de type Option 5 et 3 de FT.
1 - L'encapsulation
IP client / PPP / L2TP / UDP / IP / L2
êtes vous d'accord ?
2 - Les tailles des entêtes
PPP -> 8 octets
L2TP -> 16 octets
UDP -> 8 octets
IP -> 20 octets
L2 -> dépendant de la techno
êtes vous d'accord ?
3 - Addition
Donc, si je ne désire pas qu'il n'y ai de fragmentation, la taille du
playload supporté par le L2 doit être au minimum de :
8+16+8+20+1500(correspondant au MTU de base du client)=1552
êtes vous d'accord ?
Merci d'avance,
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"_SebF - www.frameip.com" wrote in message news:cp4ibn$32b$
Bonjour,
J'ai besoin de votre aide pour valider mes dire afin de trouver quelle est la taille maximale d'une trame L2TP véhiculée (entre le LAC et le LNS) sur un réseau de type Option 5 et 3 de FT.
1 - L'encapsulation
IP client / PPP / L2TP / UDP / IP / L2 êtes vous d'accord ?
2 - Les tailles des entêtes
PPP -> 8 octets L2TP -> 16 octets UDP -> 8 octets IP -> 20 octets L2 -> dépendant de la techno êtes vous d'accord ?
3 - Addition
Donc, si je ne désire pas qu'il n'y ai de fragmentation, la taille du playload supporté par le L2 doit être au minimum de : 8+16+8+20+1500(correspondant au MTU de base du client)52 êtes vous d'accord ?
Merci d'avance,
_SebF
http://www.frameip.com Un site pour les spécialistes IP
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données 2. la taille des entetes www.frameip.com ;-) 3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> wrote in message
news:cp4ibn$32b$1@news.tiscali.fr...
Bonjour,
J'ai besoin de votre aide pour valider mes dire afin de trouver quelle est
la taille maximale d'une trame L2TP véhiculée (entre le LAC et le LNS) sur
un réseau de type Option 5 et 3 de FT.
1 - L'encapsulation
IP client / PPP / L2TP / UDP / IP / L2
êtes vous d'accord ?
2 - Les tailles des entêtes
PPP -> 8 octets
L2TP -> 16 octets
UDP -> 8 octets
IP -> 20 octets
L2 -> dépendant de la techno
êtes vous d'accord ?
3 - Addition
Donc, si je ne désire pas qu'il n'y ai de fragmentation, la taille du
playload supporté par le L2 doit être au minimum de :
8+16+8+20+1500(correspondant au MTU de base du client)52
êtes vous d'accord ?
Merci d'avance,
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
1. encapsulation
entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
2. la taille des entetes
www.frameip.com ;-)
3. Addition
Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
"_SebF - www.frameip.com" wrote in message news:cp4ibn$32b$
Bonjour,
J'ai besoin de votre aide pour valider mes dire afin de trouver quelle est la taille maximale d'une trame L2TP véhiculée (entre le LAC et le LNS) sur un réseau de type Option 5 et 3 de FT.
1 - L'encapsulation
IP client / PPP / L2TP / UDP / IP / L2 êtes vous d'accord ?
2 - Les tailles des entêtes
PPP -> 8 octets L2TP -> 16 octets UDP -> 8 octets IP -> 20 octets L2 -> dépendant de la techno êtes vous d'accord ?
3 - Addition
Donc, si je ne désire pas qu'il n'y ai de fragmentation, la taille du playload supporté par le L2 doit être au minimum de : 8+16+8+20+1500(correspondant au MTU de base du client)52 êtes vous d'accord ?
Merci d'avance,
_SebF
http://www.frameip.com Un site pour les spécialistes IP
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données 2. la taille des entetes www.frameip.com ;-) 3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
_SebF - www.frameip.com
Hi ,
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? - Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
2. la taille des entetes www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Hi H@wk,
1. encapsulation
entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Quelques remarques,
- pourquoi Entête MAC ? et pas L2 ?
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter
autre chose ? Si Oui comment Radius va réagir ?
2. la taille des entetes
www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
3. Addition
Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
@+
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? - Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
2. la taille des entetes www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
H
"_SebF - www.frameip.com" wrote in message news:cp4lfl$904$
Hi ,
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Oui
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX? L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
2. la taille des entetes www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
L2TP: 8x16bits: 16 octets PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet mais de, par exemple, Fddi ou token ring.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
:)
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> wrote in message
news:cp4lfl$904$1@news.tiscali.fr...
Hi H@wk,
1. encapsulation
entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Oui
Quelques remarques,
- pourquoi Entête MAC ? et pas L2 ?
heu... oui, L2 c'est juste.
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter
autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de
l'ATM, du Frame Relay.
2. la taille des entetes
www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
L2TP: 8x16bits: 16 octets
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le
padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
3. Addition
Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole
de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas
d'ethernet mais de, par exemple, Fddi ou token ring.
@+
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"_SebF - www.frameip.com" wrote in message news:cp4lfl$904$
Hi ,
1. encapsulation entête MAC / entête IP / entête UDP / entête L2TP / entête PPP / Données
Tu reformules, pour confirmer ?
Oui
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX? L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
2. la taille des entetes www.frameip.com ;-)
Lol, j'ai justement besoin de vous tous.
L2TP: 8x16bits: 16 octets PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
3. Addition Mouaip! ça nous amene vers du FDDI ou du Token ring, tout ça ...
Je ne comprends pas pourquoi, ni le rapport.
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet mais de, par exemple, Fddi ou token ring.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
:)
_SebF - www.frameip.com
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant donc de la data. Cela exclus les cas de négociation de protocole, de session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille maximum des trames Ethernet devant être supporté par l'infrastructure. Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter
autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de
l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux,
as tu un lien d'exemple ?
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le
padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant
donc de la data. Cela exclus les cas de négociation de protocole, de
session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole
de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas
d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille
maximum des trames Ethernet devant être supporté par l'infrastructure.
Sachant que les équipement supporte maintennant des tailles suppérieurs à
1518. J'ai entendu parlé de 9K
@+
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant donc de la data. Cela exclus les cas de négociation de protocole, de session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille maximum des trames Ethernet devant être supporté par l'infrastructure. Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Angelot
Bonsoir Sèb et ,
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou ATM (sur PDH ou SDH, éventuellement sur WDM). De toute manière on ne note pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les adaptations ATM (telle la fragmentation).
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les réseaux d'accès ATM, le suffixe est généralement omis.
Cordialement, Angelot
Bonsoir Sèb et H@wk,
Quelques remarques,
- pourquoi Entête MAC ? et pas L2 ?
heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou
ATM (sur PDH ou SDH, éventuellement sur WDM). De toute manière on ne note
pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les
adaptations ATM (telle la fragmentation).
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les
réseaux d'accès ATM, le suffixe est généralement omis.
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou ATM (sur PDH ou SDH, éventuellement sur WDM). De toute manière on ne note pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les adaptations ATM (telle la fragmentation).
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les réseaux d'accès ATM, le suffixe est généralement omis.
Cordialement, Angelot
_SebF - www.frameip.com
Salut Angelot,
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou
ATM (sur PDH ou SDH, éventuellement sur WDM).
Dans mon cas, le backbone d'infrastructure est en Ethernet. Le but de cette architecture étant de supprimer la gestion des services géré via les Pvc par PPP et de remplacer d'instraucture ATM par de l'Ethernet.
De toute manière on ne note pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les adaptations ATM (telle la fragmentation).
Oui, mais je ne fais pas réference au modèle TCPIP, mais à OSI du fait justement que l'on ne transporte pas qu'IP. Mais ne parlons nous pas de la même chose ?
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les réseaux d'accès ATM, le suffixe est généralement omis.
Dans le cadre d'un Lan to Lan Ethernet véhiculé sur un Pvc, Le FCS est omis ?
Au fait Angelot, j'aimerais bien avoir ta confirmation. Pourrais tu répondre à mon premier message du Post ?
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Salut Angelot,
Quelques remarques,
- pourquoi Entête MAC ? et pas L2 ?
heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP
ou
ATM (sur PDH ou SDH, éventuellement sur WDM).
Dans mon cas, le backbone d'infrastructure est en Ethernet. Le but de cette
architecture étant de supprimer la gestion des services géré via les Pvc par
PPP et de remplacer d'instraucture ATM par de l'Ethernet.
De toute manière on ne note
pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les
adaptations ATM (telle la fragmentation).
Oui, mais je ne fais pas réference au modèle TCPIP, mais à OSI du fait
justement que l'on ne transporte pas qu'IP. Mais ne parlons nous pas de la
même chose ?
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les
réseaux d'accès ATM, le suffixe est généralement omis.
Dans le cadre d'un Lan to Lan Ethernet véhiculé sur un Pvc, Le FCS est omis
?
Au fait Angelot, j'aimerais bien avoir ta confirmation. Pourrais tu répondre
à mon premier message du Post ?
@+
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
Quelques remarques, - pourquoi Entête MAC ? et pas L2 ? heu... oui, L2 c'est juste.
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou
ATM (sur PDH ou SDH, éventuellement sur WDM).
Dans mon cas, le backbone d'infrastructure est en Ethernet. Le but de cette architecture étant de supprimer la gestion des services géré via les Pvc par PPP et de remplacer d'instraucture ATM par de l'Ethernet.
De toute manière on ne note pas L2 mais accès réseau, lequel comporte des fonctions L3 dans les adaptations ATM (telle la fragmentation).
Oui, mais je ne fais pas réference au modèle TCPIP, mais à OSI du fait justement que l'on ne transporte pas qu'IP. Mais ne parlons nous pas de la même chose ?
Sur réseau LAN, la trame MAC comporte un entête et un suffixe FCS. Sur les réseaux d'accès ATM, le suffixe est généralement omis.
Dans le cadre d'un Lan to Lan Ethernet véhiculé sur un Pvc, Le FCS est omis ?
Au fait Angelot, j'aimerais bien avoir ta confirmation. Pourrais tu répondre à mon premier message du Post ?
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Jacques Caron
On Tue, 7 Dec 2004 21:28:59 +0100, _SebF - www.frameip.com wrote:
Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
Yep, ce sont les Jumbo Frames. Standard sur GigE, présent sur certains équipements 10/100 un peu haut de gamme (mais je ne serais pas surpris si même des cartes à 2 balles le font aussi de nos jours).
A l'opposé, il doit encore y avoir des cartes qui traînent qui ne supportent pas un seul octet de plus que 1500, sur lesquelles on ne peut même pas faire de VLANs...
La lecture des manpages des différentes interfaces Ethernet sur un *BSD est en général assez instructive de ce point de vue. Et les sources encore plus :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Tue, 7 Dec 2004 21:28:59 +0100, _SebF - www.frameip.com
<onsespam@encore.et.encore.com> wrote:
Sachant que les équipement supporte maintennant des tailles suppérieurs à
1518. J'ai entendu parlé de 9K
Yep, ce sont les Jumbo Frames. Standard sur GigE, présent sur certains
équipements 10/100 un peu haut de gamme (mais je ne serais pas surpris si
même des cartes à 2 balles le font aussi de nos jours).
A l'opposé, il doit encore y avoir des cartes qui traînent qui ne
supportent pas un seul octet de plus que 1500, sur lesquelles on ne peut
même pas faire de VLANs...
La lecture des manpages des différentes interfaces Ethernet sur un *BSD
est en général assez instructive de ce point de vue. Et les sources encore
plus :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 7 Dec 2004 21:28:59 +0100, _SebF - www.frameip.com wrote:
Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
Yep, ce sont les Jumbo Frames. Standard sur GigE, présent sur certains équipements 10/100 un peu haut de gamme (mais je ne serais pas surpris si même des cartes à 2 balles le font aussi de nos jours).
A l'opposé, il doit encore y avoir des cartes qui traînent qui ne supportent pas un seul octet de plus que 1500, sur lesquelles on ne peut même pas faire de VLANs...
La lecture des manpages des différentes interfaces Ethernet sur un *BSD est en général assez instructive de ce point de vue. Et les sources encore plus :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jacques Caron
On Tue, 7 Dec 2004 21:39:55 +0100, Angelot wrote:
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou ATM
Ah? Moi j'ai rarement vu du PPP sur un backbone d'ISP ou de telco. Par contre j'ai vu du POS (aka POSIP, IP sur SDH/Sonet directement), de l'IP sur FR sur SDH, de l'IP sur ATM sur SDH, et toutes les variantes avec une couche de MPLS.
On voit aussi des encapsulations Ethernet dans certains cas.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Tue, 7 Dec 2004 21:39:55 +0100, Angelot <OnSePame@KesceKonSePame.fr>
wrote:
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est
PPP ou ATM
Ah? Moi j'ai rarement vu du PPP sur un backbone d'ISP ou de telco. Par
contre j'ai vu du POS (aka POSIP, IP sur SDH/Sonet directement), de l'IP
sur FR sur SDH, de l'IP sur ATM sur SDH, et toutes les variantes avec une
couche de MPLS.
On voit aussi des encapsulations Ethernet dans certains cas.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Sur le backbone, il n'existe pas 36 solutions, dans 90% des cas c'est PPP ou ATM
Ah? Moi j'ai rarement vu du PPP sur un backbone d'ISP ou de telco. Par contre j'ai vu du POS (aka POSIP, IP sur SDH/Sonet directement), de l'IP sur FR sur SDH, de l'IP sur ATM sur SDH, et toutes les variantes avec une couche de MPLS.
On voit aussi des encapsulations Ethernet dans certains cas.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
H
"_SebF - www.frameip.com" wrote in message news:cp53nr$9hv$
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
RFC 1661 PPP http://www.networksorcery.com/enp/protocol/ipx.htm et RFC1362 Novell IPX over Various WAN Media (IPXWAN)
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
RFC2661
www.faqs.org/rfcs/rfc2661.html mais je ne sais pas si il y a une implémentation qui existe.
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant donc de la data. Cela exclus les cas de négociation de protocole, de session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille maximum des trames Ethernet devant être supporté par l'infrastructure. Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
Ooops, connais pas.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
:)
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> wrote in message
news:cp53nr$9hv$1@news.tiscali.fr...
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on
transporter
autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
RFC 1661 PPP
http://www.networksorcery.com/enp/protocol/ipx.htm
et RFC1362 Novell IPX over Various WAN Media (IPXWAN)
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de
l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore
mieux,
as tu un lien d'exemple ?
RFC2661
www.faqs.org/rfcs/rfc2661.html
mais je ne sais pas si il y a une implémentation qui existe.
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le
padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant
donc de la data. Cela exclus les cas de négociation de protocole, de
session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un
protocole
de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas
d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille
maximum des trames Ethernet devant être supporté par l'infrastructure.
Sachant que les équipement supporte maintennant des tailles suppérieurs à
1518. J'ai entendu parlé de 9K
Ooops, connais pas.
@+
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"_SebF - www.frameip.com" wrote in message news:cp53nr$9hv$
- Pourquoi ne pas spécifier IP au dessus de PPP ? Peut on transporter autre chose ? Si Oui comment Radius va réagir ?
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
RFC 1661 PPP http://www.networksorcery.com/enp/protocol/ipx.htm et RFC1362 Novell IPX over Various WAN Media (IPXWAN)
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
RFC2661
www.faqs.org/rfcs/rfc2661.html mais je ne sais pas si il y a une implémentation qui existe.
L2TP: 8x16bits: 16 octets
C'est un peu l'objet de ma question, pourquoi pas :
L2TP = 6 octets ?
PPP: 1 ou 2 octets pour le champ protocole et une taille variable pour le padding. Le padding est-il nul dans le cas d'une encapsulation L2TP?
Le cas de la taille maximum se base sur des données de 1500 représantant donc de la data. Cela exclus les cas de négociation de protocole, de session, d'Ack et ....
c'est juste pour dire que sans fragmentqtion, il faut trouver un protocole de niveau 2 dont le MTU est supérieur à 1500. Ce qui n'est pas le cas d'ethernet
Si, c'est justement la finalité de ma question. De connaitre la taille maximum des trames Ethernet devant être supporté par l'infrastructure. Sachant que les équipement supporte maintennant des tailles suppérieurs à 1518. J'ai entendu parlé de 9K
Ooops, connais pas.
@+
_SebF
http://www.frameip.com Un site pour les spécialistes IP
:)
Pascal
Salut,
_SebF - www.frameip.com wrote:
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
Evidemment, sinon mon IPv6 aurait du mal à passer entre mon FAI et ma passerelle. Ce que transporte une session PPP dans un tunnel L2TP ne concerne pas L2TP.
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
C'est vrai (cf. la RFC 2661), mais la collecte IP/ADSL en option 5 de FT (ou de ses concurrents) que tu évoquais suppose par définition un transport sur UDP.
Fait chier ce crosspost. Mais là j'ai vraiment pas d'idée d'un forum plus adapté que l'autre :-
Salut,
_SebF - www.frameip.com wrote:
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au
dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
Evidemment, sinon mon IPv6 aurait du mal à passer entre mon FAI et ma
passerelle. Ce que transporte une session PPP dans un tunnel L2TP ne
concerne pas L2TP.
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de
l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux,
as tu un lien d'exemple ?
C'est vrai (cf. la RFC 2661), mais la collecte IP/ADSL en option 5 de FT
(ou de ses concurrents) que tu évoquais suppose par définition un
transport sur UDP.
Fait chier ce crosspost. Mais là j'ai vraiment pas d'idée d'un forum
plus adapté que l'autre :-
A mon avis on doit pouvoir transporter tous ce qu'on peut transporter au dessus de PPP. pourquoi pas IPX?
Quelqu'un confirme ?
Evidemment, sinon mon IPv6 aurait du mal à passer entre mon FAI et ma passerelle. Ce que transporte une session PPP dans un tunnel L2TP ne concerne pas L2TP.
L2TP n'est pas nécessairement au dessus de UDP, non plus. Ce peut etre de l'ATM, du Frame Relay.
Ha bon. Sans douter de toi, mais quelqu'un confirme t il ? Ou encore mieux, as tu un lien d'exemple ?
C'est vrai (cf. la RFC 2661), mais la collecte IP/ADSL en option 5 de FT (ou de ses concurrents) que tu évoquais suppose par définition un transport sur UDP.
Fait chier ce crosspost. Mais là j'ai vraiment pas d'idée d'un forum plus adapté que l'autre :-
