RE: Subinterfaces [7:71421]
I would think that the physical interface can only support 1 type of layer1/2 Encapsulation at one time..either frame or hdlc etc.. Larry Letterman Cisco Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Srivathsan Ananthachari Sent: Wednesday, June 25, 2003 10:54 PM To: [EMAIL PROTECTED] Subject: Subinterfaces [7:71421] Hi, Any ideas on why encapsulation is not allowed on individual FR subinterfaces but rather on the physical interface only..?? TIA Srivathsan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71425t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Hi, Well, encapsulation is done prior to placing the packets(Frames) to the physical medium - I guess it should be done on the physical interface. I would be interested in what other members have to say, but I think it makes sense that it should be on the physical interface. Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71424t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Larry, That is very correct, I think, and in a way agrees indirectly with my reasoning :) Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71426t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? I hope I'm not draggin it.../ Srivathsan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mwalie W Sent: Thursday, June 26, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: RE: Subinterfaces [7:71421] Hi, Well, encapsulation is done prior to placing the packets(Frames) to the physical medium - I guess it should be done on the physical interface. I would be interested in what other members have to say, but I think it makes sense that it should be on the physical interface. Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71427t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Hi, I think your questions are quite in order and there is no reason to feel that you are dragging it on What is the purpose of encapsulation (data-link layer)? To enable transportation of upper-layer data on the physical medium, right? It may help in this particular case to look at, for example, the fields that comprise the Frame Relay frameFlags, Address, data, FCS, Flags. The Address field contains the DLCI, representing the connection between a DTE and the Switchthis is a layer 2 address (DLCI) So, the encapsulation should actually be on the physical interface, not the software (sub)interface. May be:) Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71430t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Hi, since you also brought in the network layer into the discussion, I think it would be good to discuss some more generic questions than what you asked originally (specifically about serial/frame relay): a.) Why do I need to assign an encapsulation on the physical interface? b.) Why can I have only one encapsulation on a physical interface? c.) Why can't I specify an encapsulation on the subinterface level? My answers: a.) Encapsulation in this context really means data format. The purpose of specifying an encapsulation on the physical interface is to let the router know what is the ultimate format that should enter and especially *leave* the router on that particular *physical* interface. You can't receive/send data on a subinterface per se, you can only *logically* assign the already received data to a subinterface based on the information you extracted from the data you already received. So what would you do without having an encapsulation assigned to the physical interface? Would you check for every possible L2 format, say ATM cells on Ethernet interfaces? :) b.) If the encapsulation/decapsulation is done in hardware, and the interface hardware supports only one encapsulation per physical interface at a time, as Larry alluded to earlier, then you obviously can have only one encapsulation per physical interface. More importantly though: how would you decide in which format the information needs to be sent out if you had more than one encapsulation? c.) In general, you can. In the case of Ethernet interfaces for instance, you can specify encapsulation on a subinterface level. In fact I seem to remember that you *had* to specify it on a subinterface level for a while, and it was in fact the encapsulation type that selected the subinterface. The reason for this behavior is that Ethernet has two sub-layers within Layer 2, so even there you have an implied encapsulation assigned to the physical interface (the lower of the two sub-layers, the IEEE 802.3/Ethernet II format), and only the higher layer (layer 802.2) encapsulation is assigned to a subinterface. There was a lengthy discussion about Ethernet encapsulations on this list a few days ago, btw. At this point, the more specific question is in order: d.) Why can I not specify any encapsulation on a Serial sub-interface in IOS? Well, perhaps because the encapsulation you specified at the physical level (see above why you have to have that) took care of everything that you would characterize as encapsulation. This of course doesn't mean that all the packets assigned to a subinterface are the same, but for some reason we don't speak about IP encapsulation vs. IPX encapsulation and the like. If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? Network addresses don't specify the data format, they are the data themselves. If you wanted to ask how come I can run IP and IPX on the same interface, then the answer is because something at a lower layer will usually indicate what kind of packet you are receiving. Thanks, Zsombor At 08:55 AM 6/26/2003 +, Srivathsan Ananthachari wrote: If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? I hope I'm not draggin it.../ Srivathsan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mwalie W Sent: Thursday, June 26, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: RE: Subinterfaces [7:71421] Hi, Well, encapsulation is done prior to placing the packets(Frames) to the physical medium - I guess it should be done on the physical interface. I would be interested in what other members have to say, but I think it makes sense that it should be on the physical interface. Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71440t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Subinterfaces [7:71421]
Your point about frame map statements and layer 3 addresses brings up and interesting point. You CAN have a different kind of frame-relay encapsulation on different PVCs, and you do this with frame relay map statements. I don't have time to test it now, but I remember learning that to use frame relay IP TCP header compression, you have to use the proprietary Cisco frame relay encapsulation. So if you want to use frame relay IP TCP header compression or RTP header compression on a PVC, you configure compression using a frame map statement and that PVC then uses Cisco FR encaps (I think it is automatically transformed into a cisco FR encaps PVC). Similarly, if you have frame relay IP TCP header compression on the physical interface, you can turn off compression on a per-PVC basis using your frame map statements (nocompress comes at the end). So, you CAN have different encapsulations on a per PVC, sort of. I think all this business of cisco encapsulation working on a PVC when the interface is set to ietf (and the frame relay switch is configured for ietf) works because the FR switch doesn't really care what kind of FR encapsulation is used on each PVC, while it does care a lot about the lmi-type. The remote router needs to be set to the correct kind of FR encapsulation, though (but, again, this can be set per PVC.) Please feel free to correct me if I am wrong in any particular. I would hate to have misremembered all or some of this. Tom Larus, CCIE 10,104 Srivathsan Ananthachari wrote in message news:[EMAIL PROTECTED] If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? I hope I'm not draggin it.../ Srivathsan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mwalie W Sent: Thursday, June 26, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: RE: Subinterfaces [7:71421] Hi, Well, encapsulation is done prior to placing the packets(Frames) to the physical medium - I guess it should be done on the physical interface. I would be interested in what other members have to say, but I think it makes sense that it should be on the physical interface. Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71446t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Larry Letterman wrote: I would think that the physical interface can only support 1 type of layer1/2 Encapsulation at one time..either frame or hdlc etc.. A physical interface can support more than one encapsulation. It just depends on who it thinks is going to understand the encapsulation. The router talks to the first switch in the Frame Relay cloud, but it could also talk to more than one router across the cloud. To talk to the switch you have to have the right LMI, as we all know. The encapsulation command has to do with the router(s) at the other end. They could be using cisco or IETF and there's no good reason for Cisco to make it difficult for this to be different for different PVCS to different routers. Actually Cisco doesn't make it all that difficult. You can add encapsulation to the end of a map statement. Priscilla Larry Letterman Cisco Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Srivathsan Ananthachari Sent: Wednesday, June 25, 2003 10:54 PM To: [EMAIL PROTECTED] Subject: Subinterfaces [7:71421] Hi, Any ideas on why encapsulation is not allowed on individual FR subinterfaces but rather on the physical interface only..?? TIA Srivathsan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71449t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Zsombor Papp wrote: c.) In general, you can. In the case of Ethernet interfaces for instance, you can specify encapsulation on a subinterface level. On an Ethernet subinterface you can specify the VLAN tagging method using an encapsulation command. That is specific to a router that is doing inter-VLAN routing and needs to tag frames and you want to specify ISL or IEEE 802.1Q tagging. In general you can't specify the encapsulation used on Ethernet interfaces or subinterfaces. 802.1Q isn't really an encapsulation, in that it inserts a shim rather than surrounding the original frame, but that's for another discussion. In fact I seem to remember that you *had* to specify it on a subinterface level for a while, and it was in fact the encapsulation type that selected the subinterface. The reason for this behavior is that Ethernet has two sub-layers within Layer 2, so even there you have an implied encapsulation assigned to the physical interface (the lower of the two sub-layers, the IEEE 802.3/Ethernet II format), and only the higher layer (layer 802.2) encapsulation is assigned to a subinterface. You can't tell an Ethernet interface to use 802.2 except within the IPX network commands. Maybe you're thinking of the 802.1Q VLAN tagging standard. There was a lengthy discussion about Ethernet encapsulations on this list a few days ago, btw. But that's not what the discussion said! ;-) Ethernet encapsulation depends on the upper layer, which isn't like encapsulation on a serial interface. IP uses Ethernet Version 2: Dest Src Type (no sublayers) BPDUs use IEEE 802.3 and 802.2 Dest Src Length DSAP SSAP Control CDP, VTP, AppleTalk use IEEE 802.3, 802.2, SNAP Dest Src Length DSAP SSAP Control SNAP IPX can use any of those three or novell-ether (raw) Dest Src Length Encapsulation is set with the IPX network-layer commands becuase IPX supports 4 methods. The only major exception is for VLAN tagging. Then you can specify encapsulation with a subinterface to say whether you want ISL or 802.1Q. Ethernet encapsulation behavior isn't much like encapsulation on serial interfaces, which can only be one of the major categories: HDLC, PPP, Frame Relay. But Frame Relay has 2 varieties. Priscilla At this point, the more specific question is in order: d.) Why can I not specify any encapsulation on a Serial sub-interface in IOS? Well, perhaps because the encapsulation you specified at the physical level (see above why you have to have that) took care of everything that you would characterize as encapsulation. This of course doesn't mean that all the packets assigned to a subinterface are the same, but for some reason we don't speak about IP encapsulation vs. IPX encapsulation and the like. If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? Network addresses don't specify the data format, they are the data themselves. If you wanted to ask how come I can run IP and IPX on the same interface, then the answer is because something at a lower layer will usually indicate what kind of packet you are receiving. Thanks, Zsombor At 08:55 AM 6/26/2003 +, Srivathsan Ananthachari wrote: If it's possible to assign a network address ( IP / IPX viz., ) to the FR sub-interface why not be able to specify encap as well..?? I hope I'm not draggin it.../ Srivathsan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mwalie W Sent: Thursday, June 26, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: RE: Subinterfaces [7:71421] Hi, Well, encapsulation is done prior to placing the packets(Frames) to the physical medium - I guess it should be done on the physical interface. I would be interested in what other members have to say, but I think it makes sense that it should be on the physical interface. Mwalie Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71456t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
At 04:44 PM 6/26/2003 +, Priscilla Oppenheimer wrote: In fact I seem to remember that you *had* to specify it on a subinterface level for a while, and it was in fact the encapsulation type that selected the subinterface. The reason for this behavior is that Ethernet has two sub-layers within Layer 2, so even there you have an implied encapsulation assigned to the physical interface (the lower of the two sub-layers, the IEEE 802.3/Ethernet II format), and only the higher layer (layer 802.2) encapsulation is assigned to a subinterface. You can't tell an Ethernet interface to use 802.2 except within the IPX network commands. Maybe you're thinking of the 802.1Q VLAN tagging standard. No, I am thinking about the IPX case. Using multiple different encapsulations on a single physical interface used to be a typical question in the CCIE lab, that's why I remember it. I've never had to use it ever since, so I might have said something incorrectly, but I don't see what that was. I quickly looked at this page: http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/mods/4mod/4cbook/4cipx.htm and I think it confirmed what I said (search for subinterface within the page), but I wouldn't mind to be corrected. Ethernet encapsulation behavior isn't much like encapsulation on serial interfaces, which can only be one of the major categories: HDLC, PPP, Frame Relay. But Frame Relay has 2 varieties. I think I am missing the point here. Obviously they aren't the same, otherwise it would be foolish to give them such different names :), but I do think that the Ethernet encapsulations play a very similar role to the serial encapsulations (only in a different situation). If you mean that the original question was very Frame Relay and Cisco IOS implementation specific, and compared to that my answer was too generic and theoretical, then you are probably right. :) Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71477t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Zsombor Papp wrote: At 04:44 PM 6/26/2003 +, Priscilla Oppenheimer wrote: In fact I seem to remember that you *had* to specify it on a subinterface level for a while, and it was in fact the encapsulation type that selected the subinterface. The reason for this behavior is that Ethernet has two sub-layers within Layer 2, so even there you have an implied encapsulation assigned to the physical interface (the lower of the two sub-layers, the IEEE 802.3/Ethernet II format), and only the higher layer (layer 802.2) encapsulation is assigned to a subinterface. You can't tell an Ethernet interface to use 802.2 except within the IPX network commands. Maybe you're thinking of the 802.1Q VLAN tagging standard. No, I am thinking about the IPX case. Using multiple different encapsulations on a single physical interface used to be a typical question in the CCIE lab, that's why I remember it. I've never had to use it ever since, so I might have said something incorrectly, but I don't see what that was. Oh. Your message didn't say anything about IPX. Also, this was a weird analogy that doesn't quite work: only the higher layer (layer 802.2) encapsulation is assigned to a subinterface. Ethernet II doesn't have 802.2. Neither does novell-ether. IPX can use either of those, as well as 802.3 with 802.2 and 802.3 with 802.2 and SNAP. I quickly looked at this page: http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/mods/4mod/4cbook/4cipx.htm and I think it confirmed what I said (search for subinterface within the page), but I wouldn't mind to be corrected. Ethernet encapsulation behavior isn't much like encapsulation on serial interfaces, which can only be one of the major categories: HDLC, PPP, Frame Relay. But Frame Relay has 2 varieties. I think I am missing the point here. Obviously they aren't the same, otherwise it would be foolish to give them such different names :), but I do think that the Ethernet encapsulations play a very similar role to the serial encapsulations (only in a different situation). Ethernet encapsulation depends on the payload. IP uses Ethernet II, CDP uses SNAP, etc. With the exception of IPX, it's not configurable. (Actually ARP is configurable too for historical reasons. Long story that I can't get into now). That's not like encapsulation on a serial interface that doesn't care about the upper layer. Think about the IOS software. It has to know what it is encapsulating on Ethernet. It doesn't on a serial interface. That was what I meant by the behavior being different. Priscilla If you mean that the original question was very Frame Relay and Cisco IOS implementation specific, and compared to that my answer was too generic and theoretical, then you are probably right. :) Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71488t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
At 10:21 PM 6/26/2003 +, Priscilla Oppenheimer wrote: Oh. Your message didn't say anything about IPX. Right. I was talking about layer 2 encapsulations. I thought that the fact that *Cisco IOS* supports this configuration only for IPX is irrelevant. Maybe I was wrong, see below. Ethernet encapsulation depends on the payload. I am a bit surprised by this statement. Are you saying that the Ethernet specifications mandate the usage of, say, Ethernet II encapsulation if you want to transport IP packets? Frankly, I have never read the Ethernet specifications, but I thought that *in theory*, you can pretty much transport any payload in any Ethernet encapsulation, it's just *usually* not done. Am I mistaken? If so, can you point me to some documents that would enlighten me? (Seriously.) The fact that something is not configurable doesn't prove anything outside of the scope of the IOS implementation. As a side question, do you think that TCP must run over IP? :) Thanks, Zsombor IP uses Ethernet II, CDP uses SNAP, etc. With the exception of IPX, it's not configurable. (Actually ARP is configurable too for historical reasons. Long story that I can't get into now). That's not like encapsulation on a serial interface that doesn't care about the upper layer. Think about the IOS software. It has to know what it is encapsulating on Ethernet. It doesn't on a serial interface. That was what I meant by the behavior being different. Priscilla If you mean that the original question was very Frame Relay and Cisco IOS implementation specific, and compared to that my answer was too generic and theoretical, then you are probably right. :) Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71493t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Subinterfaces [7:71421]
Zsombor Papp wrote: At 10:21 PM 6/26/2003 +, Priscilla Oppenheimer wrote: Oh. Your message didn't say anything about IPX. Right. I was talking about layer 2 encapsulations. I thought that the fact that *Cisco IOS* supports this configuration only for IPX is irrelevant. I don't think it's irrelevant that Cisco IOS (and most operating systems) only support configuring the Ethernet encapsulation for IPX. Newbies think you can configure the Ethernet encapsulation in a generic way and for multiple protocols. You can't, and you wouldn't want to anyway if you want to interoperate with any other device. You can configure the type of VLAN tagging that should be used and then there's the IPX anomoly that we have been living with since 1981. With Cisco IOS, the fact that you can enter a generic encapsulation command on serial interfaces that affects all packets and that you can't do this on Ethernet is an important distinction that has caused confusion for numerous people on this list over the years. I thought it was worth further discussion, though not this much discussion! :-) Maybe I was wrong, see below. Ethernet encapsulation depends on the payload. I am a bit surprised by this statement. Are you saying that the Ethernet specifications mandate the usage of, say, Ethernet II encapsulation if you want to transport IP packets? No. Ethernet specs don't say what the payload will be. Frankly, I have never read the Ethernet specifications, Well, I have for what it's worth, which is not a whole lot. :-) I've read every Ethernet spec since Bob Metcalf's original memo from 1973. but I thought that *in theory*, you can pretty much transport any payload in any Ethernet encapsulation, it's just *usually* not done. Am I mistaken? No. You're not mistaken. I think it's interesting and relevant that IP always uses Ethernet II on essentially every modern operating system, even though Ethernet II is old. I think it's interesting that other protocol developers have made other choices for the encapsulation. I also know that it's an area of confusion for 1000s of students of networking, especially Cisco certification candidates, even though Cisco doesn't make you learn protocols. But I'll help people learn protocols and you can't stop me! :-) Priscilla If so, can you point me to some documents that would enlighten me? (Seriously.) The fact that something is not configurable doesn't prove anything outside of the scope of the IOS implementation. As a side question, do you think that TCP must run over IP? :) Thanks, Zsombor IP uses Ethernet II, CDP uses SNAP, etc. With the exception of IPX, it's not configurable. (Actually ARP is configurable too for historical reasons. Long story that I can't get into now). That's not like encapsulation on a serial interface that doesn't care about the upper layer. Think about the IOS software. It has to know what it is encapsulating on Ethernet. It doesn't on a serial interface. That was what I meant by the behavior being different. Priscilla If you mean that the original question was very Frame Relay and Cisco IOS implementation specific, and compared to that my answer was too generic and theoretical, then you are probably right. :) Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71498t=71421 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
