Router Subinterface Mac Address

My understanding is that a SINGLE mac address can be associated with an interface.  Thus a layer 2 packet rewrite associated with ANY subinterface will always use the mac address of the physical interface. The new streaming CCNA that I reviewed indicated that a separate mac address will exist for each subinterface.  If I am to develop a proper foundation for CCIE study, I must master important details and banish common assumptions.  Clarification will be appreciated.

Ernie

Comments

  • Earlier most routers and switches would allocate a unique MAC address for every subinterface/SVI. This was a waste of resources though. Now they will mostly use the same MAC-address. At least if the subinterfaces are located under the same physical interface. Here is a quick test I did in GNS3. I created 3 subinterfaces under the same physical interface.

    R1#sh int | i Fast|bia
    FastEthernet0/0 is up, line protocol is up
      Hardware is Gt96k FE, address is c200.1b38.0000 (bia c200.1b38.0000)
    FastEthernet0/0.1 is up, line protocol is up
      Hardware is Gt96k FE, address is c200.1b38.0000 (bia c200.1b38.0000)
    FastEthernet0/0.2 is up, line protocol is up
      Hardware is Gt96k FE, address is c200.1b38.0000 (bia c200.1b38.0000)
    FastEthernet0/0.3 is up, line protocol is up

    As you can see the MAC address is the same and that is fine. The router terminates the VLAN so it does not matter that MAC address is the same.

  • Hi Ernie,

    Can you point us to the Video# in which this was explained?

    Thanks,
    Erwin

    On Sat, Dec 17, 2011 at 1:00 AM, Ernie_07 wrote:
    > My understanding is that a SINGLE mac address can be associated with an
    > interface.  Thus a layer 2 packet rewrite associated with ANY subinterface
    > will always use the mac address of the physical interface. The new streaming
    > CCNA that I reviewed indicated that a separate mac address will exist for
    > each subinterface.  If I am to develop a proper foundation for CCIE study, I
    > must master important details and banish common assumptions.  Clarification
    > will be appreciated.
    >
    > Ernie
    >
    >
    >
    >
    > Internetwork Expert - The Industry Leader in CCIE Preparation
    > http://www.internetworkexpert.com
    >
  • Hi Erwin,

    Daniel has shed some light upon my confusion.  He pointed out that older routers provided unique mac addresses for subinterfaces while newer ones assign the mac address of a physical interface to each of its subinterfaces.  This appears to be a hardware-dependent issue rather than an error within the CCNA VOD.  I am hoping that his findings will be confirmed using recent and perhaps older router hardware.  If so, this tidbit will get added to a growing list of hardware gotchas such as the DTP default differences between a 3550 and 3560 switch.  Two 3560's will not form a trunk by default.

    Ernie

  • Hi Ernie,

    As far as I know the 2600's did behave the same.

    For example:
    ===
    There are also articles on the www that describe issues with DHCP in
    combination with sub-interfaces.

    Suppose you would like to enable dhcp on both sub-interfaces?
    The dhcp-server would assign you an IP based on the MAC. And in this
    case, the MAC is the same for both interfaces and they are in the same
    L2 network.

    How could the dhcp-server see the difference in the dhcp-request from
    the different sub-interfaces?

    The solution was to use the "client-id". If the dhcp-server supports
    this option, it could distinct based on the client-id instead of the
    mac-address.
    Router(config-if)# ip address dhcp [client-id interface name]
    ===


    Maybe you are right that much older routers behaved differently, but
    chances are that Brian was trying to point out something differently.
    (Still curious which CCNA video to review)

    Thanks,
    Erwin



    On Sat, Dec 17, 2011 at 8:44 AM, Ernie_07 wrote:
    > Hi Erwin,
    >
    > Daniel has shed some light upon my confusion.  He pointed out that older
    > routers provided unique mac addresses for subinterfaces while newer ones
    > assign the mac address of a physical interface to each of its subinterfaces.
    >  This appears to be a hardware-dependent issue rather than an error within
    > the CCNA VOD.  I am hoping that his findings will be confirmed using recent
    > and perhaps older router hardware.  If so, this tidbit will get added to a
    > growing list of hardware gotchas such as the DTP default differences between
    > a 3550 and 3560 switch.  Two 3560's will not form a trunk by default.
    >
    > Ernie
    >
    >
    >
    >
    > Internetwork Expert - The Industry Leader in CCIE Preparation
    > http://www.internetworkexpert.com
    >
  • The 3750s also use the same MAC for every subif. But maybe it depends on the IOS and the MAC-addresses bound to the eeprom chip onboard.

     

    Regards!

  • Hi Ernie,

    I did a quick look on this on different platforms, I got same MAC address to all subinterfaces:

    R1#show int fa1/1 | in bia
      Hardware is i82543 (Livengood), address is ca00.1558.001d (bia ca00.1558.001d)
    R1#show int fa1/1.10 | in bia
      Hardware is i82543 (Livengood), address is ca00.1558.001d (bia ca00.1558.001d)
    R1#show int fa1/1.20 | in bia
      Hardware is i82543 (Livengood), address is ca00.1558.001d (bia ca00.1558.001d)

    HAPPY STUDY

    [:D]

  • I've never seen (so far) different MAC addresses on subinterfaces of a physical interface, so would love to see an output from a router which does so.

    BTW, can anyone explain in what situation the same MAC address on different physical interfaces can be an issue?

  • Hi Sey,

    Suppose f0/0 and f0/1 of a router would have the same MAC address, you
    would not be able to connect them to the same L2 domain.
    The switch would learn the MAC-address on two ports and report "mac-flapping"

    On logical interfaces (which obviously connect to the same switchport
    and the same L2 domain) the only issue I am aware of is with DHCP.

    Erwin
  • The newer codes use the MAC from the interface, which is aka MAC minimization...The code used on the CCIE also use the MAC for all the sub-interfaces, so nothing to worry about..

  • It would seem to me that manually configuring default gateway IP addresses on SVI's or router-on-a stick subinterfaces and configuring a DHCP server to provide appropriate addressing for hosts would be preferred over trying to accomplish total addressing via a DHCP server.

    Can some of you grey beards provide a thumbs up on my thoughts?

    On the other hand if I've missed something important please jump up and down and shout. Thanks in advance for helping me to prepare for CCIE studies.

    Ernie

  • Hi,

     

    The way the routers/devices make sure things are unique is an extension of how it works on the switches (and QinQ stacking for SPs) and that's by the use of an additional field, that is in this case, is the 802.1Q 4 byte tag header.  If you add a unique header to the same inside information (BIA) you get a unique result.

     

    Take these outputs from BB2 from INE's Vol II WB GNS3:

     

     

    BB2#sh int fa0/0.1 | i bia|ID

      Hardware is Gt96k FE, address is c20d.ea95.0000 (bia c20d.ea95.0000)

      Encapsulation 802.1Q Virtual LAN, Vlan ID  1.

    BB2#sh int fa0/0.2 | i bia|ID

      Hardware is Gt96k FE, address is c20d.ea95.0000 (bia c20d.ea95.0000)

      Encapsulation 802.1Q Virtual LAN, Vlan ID  2.

    BB2#sh int fa0/0 | i bia|ID  

      Hardware is Gt96k FE, address is c20d.ea95.0000 (bia c20d.ea95.0000)

    BB2#sh ip int bri | i up

    FastEthernet0/0            192.10.1.254    YES NVRAM  up                    up      

    FastEthernet0/0.1          10.184.1.1      YES manual up                    up      

    FastEthernet0/0.2          10.184.2.2      YES manual up                    up      

    Loopback0                  220.20.3.1      YES NVRAM  up                    up      

    Loopback1                  222.22.2.1      YES NVRAM  up                    up      

    Loopback3                  205.90.31.1     YES NVRAM  up                    up      

    Loopback51515151           51.51.51.51     YES NVRAM  up                    up      

    BB2#

     

    And add this to the fact that when you create more than one subinterface on a routed port it becomes a Dot1Q trunk, see here:







    VLAN Subinterface and 802.1Q Trunking Overview

    Subinterfaces let you divide a physical or redundant interface into multiple logical interfaces that are tagged with different VLAN IDs. An interface with one or more VLAN subinterfaces is automatically configured as an 802.1Q trunk. Because VLANs allow you to keep traffic separate on a given physical interface, you can increase the number of interfaces available to your network without adding additional physical interfaces or security appliances.

     

    Giving you the answer you need.  As Daniel correctly states the routing device usually terminates the L2 domain but not always as IRB and CRB can and does occour - I'm unsure if you can use subinterfaces with I/CRB - but it doesn't matter as any frame is still tagged as belonging to a separate L2 and therefore L3 domain.

     

    Good luck.

     

  • Hi,

    This topic is listed in CCNA static vs Dynamic routing video by Bryan. In the Video it was described that each subinterface will be assigned a seperate MAC address so that L2 header rewriting will happen. As I was going though the above discussion, I understand that older Cisco boxes used to assign different MAC for subinterfaces but the newer box uses single MAC (MAC of the physical interface) for the subinterfaces. Then my question is how the L2 packet rewriting will take place?

    Please correct me if I am wrong or missing something here.

     

  • This is my topology: R1, R2, and R3 are all connected to a switch. This is like a Hub and Spoke topology where R2 is the hub and has two sub-interfaces to R1 and R3 with VLANs of 10 and 20 respectively.

    R1's BIA: aabb.cc00.0100
    R2's BIA: aabb.cc00.0300
    R3's BIA: aabb.cc00.0400

    Here is the packet capture:
    I did a ping from R1 to R3, the frame contains the Src MAC of R1 and Dst MAC of R2

    [View:http://ieoc.com/themes/calypso/utility/[url=http://postimg.org/image/ohmj24d7d/][img]http://s28.postimg.org/ohmj24d7d/image.jpg[/img][/url]:815:38]

    R2 rewrite the frame and make the Src MAC of R2 and Dst MAC of R3

    [View:http://ieoc.com/themes/calypso/utility/[url=http://postimg.org/image/gdeexdqs9/][img]http://s28.postimg.org/gdeexdqs9/image.jpg[/img][/url]:811:39]

     

    HTH, 
    Tim 

    Hope this helps!

    Timothy Q. Manito

  • hi Tim,

    great! So I assume that you connected R1 & R3 roter to 2 subinterface under the same physical interface. If my this assumtion is correct then R2 hub/switch allocated 2 different MAC to 2 sub-interface and then the L2 rewrite was happened. Please correct me if I am wrong.

     

     

  • Hi,

    this is the connections of Routers, R1-e0/0.10===e0/0.10-R2-e0/0.20====e0/0.20-R3
    R2 uses only One MAC address, it does not create another MAC address for sub-interfaces.

    HTH,
    Tim 

    Hope this helps!

    Timothy Q. Manito

  • peetypeety ✭✭✭

    My understanding is that a SINGLE mac address can be associated with an interface.  Thus a layer 2 packet rewrite associated with ANY subinterface will always use the mac address of the physical interface. The new streaming CCNA that I reviewed indicated that a separate mac address will exist for each subinterface.  If I am to develop a proper foundation for CCIE study, I must master important details and banish common assumptions.  Clarification will be appreciated.

    Clarification can be found by labbing this up. Regardless, does it matter? Two subinterfaces, or a physical and a sub, won't be in the same VLAN, so the fact that the same packet possibly flowed through two VLANs with the same MAC isn't a problem.

  • peetypeety ✭✭✭

    If so, this tidbit will get added to a growing list of hardware gotchas such as the DTP default differences between a 3550 and 3560 switch.  Two 3560's will not form a trunk by default.

    You're correct. Again, does it matter? Explicitly configuring the switchport mode is definitely NOT a form of overconfiguration. I call it "definitive configuration". I encourage you to decide what mode you want the port to be in, and then configure it that way. If your configuration disappears, great, you found the default, and NVGEN happens to hide that from you if configured to default, but you configured it explicitly and that's a good thing.

    I come from the service provider space, and therefore I personally don't see a reason why anyone would want dynamic desirable OR auto. If you've got a link that's supposed to be a trunk, it's supposed to be a trunk, so make it a trunk. If you're really concerned about it, set an access VLAN that either solves your biggest need, or raises red flags so you can more quickly discover that the port isn't trunking.

Sign In or Register to comment.