networking-forum.com - View topic - Router-on-a-stick with native dot1q vlan

Board index » Cisco Networking » Cisco Routing and Switching

All times are UTC - 6 hours [ DST ]

Router-on-a-stick with native dot1q vlan

Page 1 of 1

[ 18 posts ]

Print view

Previous topic | Next topic

Author

Message

chrismarget

Post subject: Router-on-a-stick with native dot1q vlan

Posted: Thu Jul 26, 2012 7:36 pm

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

Is there any practical difference between:

Code:

int fa 0/0
 no ip address
 no shut
int fa 0/0.2
 encap dot1q 2
 ip address 2.2.2.2 255.255.255.0
int fa 0/0.3
 encap dot1q 3 native
 ip address 3.3.3.3 255.255.255.0

and

Code:

int fa 0/0
 ip address 3.3.3.3 255.255.255.0
 no shut
int fa 0/0.2
 encap dot1q 2
 ip address 2.2.2.2 255.255.255.0

Thanks!

Top

burnyd

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Thu Jul 26, 2012 7:42 pm

Post Whore

Joined: Fri Nov 13, 2009 5:15 pm
Posts: 2053
Location: Pittsburgh
Certs: CCIE R&S,CCIP,JNCIA,VCP510

uses vlan 3 as the native vlan... but I believe certain platforms will tag the native vlan.

_________________
"I will prepare and some day my chance will come." - Abraham Lincoln
http://danielhertzberg.wordpress.com - I blog about networks!

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Thu Jul 26, 2012 7:58 pm

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

burnyd wrote:

uses vlan 3 as the native vlan...

Both configuration samples accomplish that. Are they different at all?

Quote:

but I believe certain platforms will tag the native vlan.

sounds awfully non-native-y

Top

Vito_Corleone

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Thu Jul 26, 2012 8:31 pm

Moderator

Joined: Mon Apr 07, 2008 10:38 am
Posts: 9439
Location: Orlando, FL
Certs: CCNP RS, CCNP DC, CCDP, CCIP

Edit: Duh.

I don't think the first config works, does it?

Edit2: Looks like the router takes it. Assuming it functions, I don't see a difference. I've never seen/done an IP on the physical interfaced of a subinterfaces interface. Fun sentence.

_________________
http://blog.alwaysthenetwork.com

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Thu Jul 26, 2012 8:44 pm

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

There is a difference:

Using the 'encap dot1q X native' directive causes this subinterface to accept untagged traffic (which is what it generates) OR traffic tagged with VLAN X.

An IP address assigned to a physical interface can't do that. Is this a good thing? I'm not sure.

This, incidentally, is the similar to the behavior of the 'vlan dot1q tag native' command on Catalysts, except it works the other way: The catalyst accepts tagged or untagged traffic, but generates tagged traffic.

Putting these two features together allows crazy interaction like I've captured here:

Code:

Frame 3 (114 bytes on wire, 114 bytes captured)
    Arrival Time: Jul 26, 2012 21:37:40.960823000
    [Time delta from previous captured frame: 0.298311000 seconds]
    [Time delta from previous displayed frame: 0.298311000 seconds]
    [Time since reference or first frame: 0.333150000 seconds]
    Frame Number: 3
    Frame Length: 114 bytes
    Capture Length: 114 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:icmp:data]
Ethernet II, Src: ca:00:08:7a:00:08 (ca:00:08:7a:00:08), Dst: Cisco_67:bf:00 (00:0b:fd:67:bf:00)
    Destination: Cisco_67:bf:00 (00:0b:fd:67:bf:00)
        Address: Cisco_67:bf:00 (00:0b:fd:67:bf:00)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: ca:00:08:7a:00:08 (ca:00:08:7a:00:08)
        Address: ca:00:08:7a:00:08 (ca:00:08:7a:00:08)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 2.2.2.10 (2.2.2.10), Dst: 2.2.2.1 (2.2.2.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 100
    Identification: 0xb79b (47003)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (0x01)
    Header checksum: 0xfbee [correct]
        [Good: True]
        [Bad : False]
    Source: 2.2.2.10 (2.2.2.10)
    Destination: 2.2.2.1 (2.2.2.1)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0xf26f [correct]
    Identifier: 0x0012
    Sequence number: 0 (0x0000)
    Data (72 bytes)

0000  00 00 00 00 00 48 8b 80 ab cd ab cd ab cd ab cd   .....H..........
0010  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0020  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0030  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0040  ab cd ab cd ab cd ab cd                           ........
        Data: 0000000000488B80ABCDABCDABCDABCDABCDABCDABCDABCD...
        [Length: 72]

Frame 4 (118 bytes on wire, 118 bytes captured)
    Arrival Time: Jul 26, 2012 21:37:40.961327000
    [Time delta from previous captured frame: 0.000504000 seconds]
    [Time delta from previous displayed frame: 0.000504000 seconds]
    [Time since reference or first frame: 0.333654000 seconds]
    Frame Number: 4
    Frame Length: 118 bytes
    Capture Length: 118 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:vlan:ip:icmp:data]
Ethernet II, Src: Cisco_67:bf:00 (00:0b:fd:67:bf:00), Dst: ca:00:08:7a:00:08 (ca:00:08:7a:00:08)
    Destination: ca:00:08:7a:00:08 (ca:00:08:7a:00:08)
        Address: ca:00:08:7a:00:08 (ca:00:08:7a:00:08)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: Cisco_67:bf:00 (00:0b:fd:67:bf:00)
        Address: Cisco_67:bf:00 (00:0b:fd:67:bf:00)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 2
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = CFI: 0
    .... 0000 0000 0010 = ID: 2
    Type: IP (0x0800)
Internet Protocol, Src: 2.2.2.1 (2.2.2.1), Dst: 2.2.2.10 (2.2.2.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 100
    Identification: 0xb79b (47003)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (0x01)
    Header checksum: 0xfbee [correct]
        [Good: True]
        [Bad : False]
    Source: 2.2.2.1 (2.2.2.1)
    Destination: 2.2.2.10 (2.2.2.10)
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 ()
    Checksum: 0xfa6f [correct]
    Identifier: 0x0012
    Sequence number: 0 (0x0000)
    Data (72 bytes)

0000  00 00 00 00 00 48 8b 80 ab cd ab cd ab cd ab cd   .....H..........
0010  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0020  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0030  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0040  ab cd ab cd ab cd ab cd                           ........
        Data: 0000000000488B80ABCDABCDABCDABCDABCDABCDABCDABCD...
        [Length: 72]

An untagged ping got a tagged response. Nifty.

Top

mellowd

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Fri Jul 27, 2012 2:32 am

CCIE #38070

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12488
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP

There is an operational difference as well. If you put the IP on the subinterface and tag native, you can shut down that subinterface without affecting any other subinterface. But if you put that same IP address on the physical interface and need to shut it, you shut all the other subinterfaces on that interface as well.

The actual frames generated for traffic leaving the native subinterface or physical interface are exactly the same. i.e. no dot1q tag.

I did not know that a native subinterface will accept also tagged frames for the vlan it considers native. That is good to know

_________________
www.mellowd.co.uk/ccie/

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Fri Jul 27, 2012 7:49 am

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

mellowd wrote:

If you put the IP on the subinterface and tag native, you can shut down that subinterface without affecting any other subinterface. But if you put that same IP address on the physical interface and need to shut it, you shut all the other subinterfaces on that interface as well.

Ah, good point. It's perfectly obvious now that you point it out, but I hadn't thought of that.

Thanks!

Top

dieselboy

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 12:49 am

Post Whore

Joined: Tue Aug 05, 2008 6:36 am
Posts: 2426
Location: Perth, Australia
Certs: CCNP, CCNA Voice, SMB Select, Linux+

Vito_Corleone wrote:

I have only built my networks this way (first config example). In most cases for the small networks I build it's not viable to configure a separate OOB management interface, so the inside interface will be used for management too.

In service provider networks I can see the benefit of splitting them for the benefits that Darren mentioned. In small networks I've found the first config to be better and more logical - ie the physical interface does not tag, however you expect a subinterface to be tagging. However in a service provider network I would expect every frame to be tagged, anyway and there to be very little or no traffic using VLAN 1.

I was suprised to see how many people don't use the physical interface, some believed that putting an IP on, it didn't work when you had sub interfaces too. Actually my boss told me to fix my config once as it could be causing problems due to the physical IP and sub interfaces.

Since I've seen your comment too, now I think may be that some older devices may have had issues being configured this way, is this correct?

_________________
"Right actions in the future are the best apologies for bad actions in the past."

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 7:47 am

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

I'm not aware of any older devices have a problem in this regard.

What's your use case for using native VLAN in a router-on-a-stick scenario, anyway?

With the exception of some access ports that genuinely require the use of untagged traffic, I generally:
- leave the native VLAN as "1" on all trunks
- disallow VLAN 1 from all interfaces (trunk and otherwise)

I can't think of a reason that I'd want to intermingle tagged and untagged traffic on a link between two network devices. What's the use case for doing that?

Oh, and BTW Darren - are we writing each other's blog posts now? ;-)

Top

mellowd

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 7:51 am

CCIE #38070

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12488
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP

Heh. I thought it would make a good post.

I've had to use tagged and untagged frames on the same interface before, but mainly as a temporary measure. i.e. I'm changing an untagged frame to tagged, but with no disruption to current service. At a later maintenance window I can then change both to tagged.

_________________
www.mellowd.co.uk/ccie/

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 8:25 am

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

Me too - We stumbled into a strange corner here.

Ahh, migration is a good use case: router to switch running untagged, need a new adjacency, but have no spare interfaces, so you wind up with old untagged + new tagged.

Other than voice interfaces, the cases where I've required a untagged traffic on a tagging interface were due to server requirements:
- server boots via PXE (untagged), but needs to access many VLANs once it's up
- server admins don't understand VLANs, but think they might need them in the future, so I gave 'em a trunk with only the untagged VLAN allowed.

Top

dieselboy

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 8:40 am

Post Whore

Joined: Tue Aug 05, 2008 6:36 am
Posts: 2426
Location: Perth, Australia
Certs: CCNP, CCNA Voice, SMB Select, Linux+

chrismarget wrote:

I must apologise that I neglected to remember the title of the thread was router on a stick. Who uses router on a stick in an actual network design anyway? I've just spent the last four or five months getting rid of routers on sticks.
And I generally follow the same design principles as you, I never use VLAN 1 for anything and it never exists on trunks as I only allow the VLANs required.

To answer your question why you would want to intermingle tagged and untagged, I've found in my experience of these small networks and sometimes large; that occasionally people unpatch something they shouldnt. They then forget where they unpatched it from when they realise they broke something and they then stick it back anywhere. In my designs we normally have PC's for example on access ports. Next to them we might have uplinks to routers or other network equipment using a trunk. Using untagged frames on the connections to the routers etc has got us out of a site visit when a router / access point / other device has gone down because the main network stays up if that router is then plugged into a PC access port. Just some other VLANs go down instead. I've had this happen once with a router but plenty of times with wireless access points. Plus, since the network is up and everything is contactable - we get SNMP alerted that the proper router / AP port is down and we can also jump on and tell the customer someones unpatched something.

_________________
"Right actions in the future are the best apologies for bad actions in the past."

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 9:38 am

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

Oh man, that's brutal. You're designing your network to limp along after someone moves cables at random?

That's a solid use case, but it's a bummer that it's come to this for you.

Top

mlan

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 12:07 pm

Senior Member

Joined: Thu Nov 17, 2011 6:09 pm
Posts: 498
Location: Portland, OR

dieselboy wrote:

[snip]Who uses router on a stick in an actual network design anyway?

Why is this a poor design? What am I missing here? With proper port-channel redundancy and HSRP/GLBP in place, I am not coming up with too many negatives, other than some hardware complexity.

Top

chrismarget

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 12:53 pm

Senior Member

Joined: Wed Jan 26, 2011 3:38 pm
Posts: 386
Location: New Hampshire

mlan wrote:

dieselboy wrote:

[snip]Who uses router on a stick in an actual network design anyway?

Why is this a poor design?

I'm sure others will have opinions about this. Off the top of my head:

- slow convergence due to lack of direct feedback about L3 neighbor failure
- L3 throughput constrained to half-duplex link speed
- multilayer switches can do this anyway
- routers are more expensive than switches if you're looking at $/throughput

Top

dieselboy

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Mon Jul 30, 2012 11:05 pm

Post Whore

Joined: Tue Aug 05, 2008 6:36 am
Posts: 2426
Location: Perth, Australia
Certs: CCNP, CCNA Voice, SMB Select, Linux+

chrismarget wrote:

Oh man, that's brutal. You're designing your network to limp along after someone moves cables at random?

That's a solid use case, but it's a bummer that it's come to this for you.

Well yes, I would rather the network limp along and still work (meaning users can trade without issue) than the network die altogether and require a site visit as we have no visibility, for example.

It just happens sometimes. A lot of the networks have been in managed office space so that has been a factor. Also some of our clients believe they really are IT managers and want to plug their own things in. After all, it is their network. I suppose this comes from working as an outsourced company rather than in-house. The things I pick up tend to stay with me and as such have been implementing from experience going forward.

Mlan: I'm keen to see your positives for router on a stick?

Another positive for not using a router on a stick design is that you can easily refer to a network diagram and visualise traffic paths, as a router or other device would be in path in a diagram and in real life.
Another one is that WAN optimisation devices work better being connected in-path without an on-a-stick design.

_________________
"Right actions in the future are the best apologies for bad actions in the past."

Top

ristau5741

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Tue Jul 31, 2012 7:51 am

Post Whore

Joined: Tue Aug 21, 2007 2:15 pm
Posts: 8459
Location: Frederick MD
Certs: Instanity

dieselboy wrote:

chrismarget wrote:

Another positive for not using a router on a stick design is that you can easily refer to a network diagram and visualise traffic paths, as a router or other device would be in path in a diagram and in real life.
Another one is that WAN optimisation devices work better being connected in-path without an on-a-stick design.

ACL's can get real hairy with RoS

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw

Top

mlan

Post subject: Re: Router-on-a-stick with native dot1q vlan

Posted: Tue Jul 31, 2012 11:56 am

Senior Member

Joined: Thu Nov 17, 2011 6:09 pm
Posts: 498
Location: Portland, OR

Thanks for the feedback. I had a specific situation in my head (underpowered multi-layer switches being used for internal routing), but it doesn't hold up against the bigger design issues you all listed. It has given me something to think about, which is always a good thing.

Top

Page 1 of 1

[ 18 posts ]

Board index » Cisco Networking » Cisco Routing and Switching

All times are UTC - 6 hours [ DST ]

Who is online

Users browsing this forum: astorrs, Bing [Bot], m4rtin, rcmagararu, totaluser and 28 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum