Tags: 1qtagged, anti-virus, browser, ethernet-ccc, handoff, heck, interface, l2circuit, network, networking, security, vlan-ccc
l2circuit between vlan-ccc and ethernet-ccc
On Networking » Networking
7,784 words with 8 Comments; publish: Sun, 04 May 2008 15:51:00 GMT; (45046.88, « »)
How the heck do you set up an l2circuit between a vlan-ccc interface (.1q
tagged on the handoff) on one end, and a ethernet-ccc handoff (not .1q
tagged) on the other end? If you just configure it like normal you get
EM/encapsulation mismatch on the l2circuit, but since the .1q tag is not
included in the actual payload put on the LSP, they should actually be the
same packet internally yes? Doesn't seem to be an issue covered in any
documentation. :)
http://network.itags.org/q_networking-tech_132199.html
All Comments
Leave a comment...
- 8 Comments
- How the heck do you set up an l2circuit between a vlan-ccc interface (.1q
tagged on the handoff) on one end, and a ethernet-ccc handoff (not .1q
tagged) on the other end? If you just configure it like normal you get
EM/encapsulation mismatch on the l2circuit, but since the .1q tag is not
included in the actual payload put on the LSP, they should actually be the
same packet internally yes?
Um, why do you think the .1q tag is not put on the LSP for the vlan-ccc
interface? As far as I know it is.
You may be able to get around this by using a vlan-map with an explicit
pop/push operation (haven't tried it though).
Steinar Haug, Nethelp consulting, sthaug (AT) nethelp (DOT) no
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
#1; Sun, 04 May 2008 15:52:00 GMT
- How the heck do you set up an l2circuit between a vlan-ccc interface (.1q
tagged on the handoff) on one end, and a ethernet-ccc handoff (not .1q
tagged) on the other end? If you just configure it like normal you get
EM/encapsulation mismatch on the l2circuit, but since the .1q tag is not
included in the actual payload put on the LSP, they should actually be the
same packet internally yes?
Um, why do you think the .1q tag is not put on the LSP for the vlan-ccc
interface? As far as I know it is.
You may be able to get around this by using a vlan-map with an explicit
pop/push operation (haven't tried it though).
Tried it, it *appears* to work (l2circuit comes up):
ge-1/3/0 {
vlan-tagging;
encapsulation vlan-ccc;
unit 513 {
encapsulation vlan-ccc;
vlan-id 513;
input-vlan-map pop;
output-vlan-map push;
}
}
l2circuit {
neighbor a.b.c.d {
interface ge-1/3/0.513 {
virtual-circuit-id 999;
}
}
}
and
fe-3/2/3 {
encapsulation ethernet-ccc;
unit 0;
}
l2circuit {
neighbor e.f.g.h {
interface fe-3/2/3.0 {
virtual-circuit-id 999;
}
}
}
Haven't verified that traffic actually gets through though.
Steinar Haug, Nethelp consulting, sthaug (AT) nethelp (DOT) no
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
#2; Sun, 04 May 2008 15:53:00 GMT
- I believe you can't specify the PW type manually in Junos, specifically
type 0x0004 Tagged vs 0x0005 Ethernet (raw).
=) P
Fri, 28 2005, Richard A Steenbergen wrote:
How the heck do you set up an l2circuit between a vlan-ccc interface (.1q
tagged on the handoff) on one end, and a ethernet-ccc handoff (not .1q
tagged) on the other end? If you just configure it like normal you get
EM/encapsulation mismatch on the l2circuit, but since the .1q tag is not
included in the actual payload put on the LSP, they should actually be the
same packet internally yes? Doesn't seem to be an issue covered in any
documentation. :)
--
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
#3; Sun, 04 May 2008 15:54:00 GMT
- So to summarize:
1. Juniper does carry the vlan-ccc vlan tag in the LSP?
2. You can't directly make vlan-ccc and ethernet-ccc talk to each other?
3. The only hack is with SFP/QPP interfaces which can do vlan-map?
4. No other workarounds exist (tcc does not apply, etc)?
Cute. Don't tell me I'm the first person to actually want to do this. :)
#4; Sun, 04 May 2008 15:55:00 GMT
- I'm not very familiar with switching but maybe you can do what you want
with VPLS instead of l2circuit.
Pablo
Mon, 31 2005 15:16:57 -0500, "Richard A Steenbergen"
<ras (AT) e-gerbil (DOT) netsaid:
So to summarize:
1. Juniper does carry the vlan-ccc vlan tag in the LSP?
2. You can't directly make vlan-ccc and ethernet-ccc talk to each other?
3. The only hack is with SFP/QPP interfaces which can do vlan-map?
4. No other workarounds exist (tcc does not apply, etc)?
Cute. Don't tell me I'm the first person to actually want to do this. :)
#5; Sun, 04 May 2008 15:56:00 GMT
- I'm not very familiar with switching but maybe you can do what you want
with VPLS instead of l2circuit.
Why on earth would you want to use a more complex technology (VPLS)
when a simple point to point link will do?
Steinar Haug, Nethelp consulting, sthaug (AT) nethelp (DOT) no
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
#6; Sun, 04 May 2008 15:57:00 GMT
- Thu, Nov 24, 2005 at 03:10:54PM -0500, Alex Rubenstein wrote:
I am starting to play around with sampling/netflow on Juniper, and have
run into an interesting thing.
First off, my config:
sampling {
input {
family inet {
rate 1024;
run-length 5;
}
}
output {
file filename some-file size 5m;
cflowd x.x.x.x {
port 4200;
version 5;
local-dump;
autonomous-system-type origin;
}
}
}
Unrelated, but you probably want a rate that is a round number (divisible
by the run-length). Your current settings would require you to multiply
the data by 204.8 to get back to your original data. :)
I've homebrewed a collector, just for testing. I've then enabled sampling
on one interface on the above router, an interface I know the traffic on.
In the some-file, I am getting good stuff. All valid, it appears.
However, in the netflow packets, I am getting odd packets once in a while:
src ifindex: 0
dst ifindex: 4352
bytes : 354025472
src asn : 0
dst asn : 1
src ip : 8.53.121.140
dst ip : 8.53.121.140
or
src ifindex: 16
dst ifindex: 1536
bytes : 403505152
src asn : 0
dst asn : 1
src ip : 140.44.95.91
dst ip : 140.44.95.91
Perhaps 20 to 50% of the rec'd records are like that.
There is no ifindex as indicated above. 140.44.95.91 isn't even in our
routing table. Notice the size of the flow. Very odd. in old 6.x
and new 7.x.
I'd check your collector code first, are you certain your alignment is
correct for packets which contain multiple flows?
#7; Sun, 04 May 2008 15:58:00 GMT
- I am starting to play around with sampling/netflow on Juniper, and have
run into an interesting thing.
First off, my config:
sampling {
input {
family inet {
rate 1024;
run-length 5;
}
}
output {
file filename some-file size 5m;
cflowd x.x.x.x {
port 4200;
version 5;
local-dump;
autonomous-system-type origin;
}
}
}
I've homebrewed a collector, just for testing. I've then enabled sampling
on one interface on the above router, an interface I know the traffic on.
In the some-file, I am getting good stuff. All valid, it appears.
However, in the netflow packets, I am getting odd packets once in a while:
src ifindex: 0
dst ifindex: 4352
bytes : 354025472
src asn : 0
dst asn : 1
src ip : 8.53.121.140
dst ip : 8.53.121.140
or
src ifindex: 16
dst ifindex: 1536
bytes : 403505152
src asn : 0
dst asn : 1
src ip : 140.44.95.91
dst ip : 140.44.95.91
Perhaps 20 to 50% of the rec'd records are like that.
There is no ifindex as indicated above. 140.44.95.91 isn't even in our
routing table. Notice the size of the flow. Very odd. in old 6.x
and new 7.x.
Thoughts?
#8; Sun, 04 May 2008 15:59:00 GMT