Quantcast
Channel: All Ethernet Switching posts
Viewing all 10307 articles
Browse latest View live

Re: Daisy Chaining EX-series switches

$
0
0

If I understand correctly the orange distribution switchs are a virtual chassis.  Hence they are logically a single switch.

 

As a result you can make the dual connections of each blue access switch an ae bundle connecting to an ae bundle on the orange switch.  Thus a single connection, no loops possible, but with full hardware redundancy.

 

This makes better use of the links and still maintains the hardware redunancy.  Removing the need for spanning tree at all in the distribution to access layer.

 

I think that is what the proposal is saying, and I would agree. 

Assuming I understand the setup correctly.

 


Re: Daisy Chaining EX-series switches

$
0
0

Steve,

 

Thank you for giving your response,

 

The blue lines are indeed (also) ae links. The question is about daisy chaning a new switch via an ae interface to an existing (blue) access switch. The new daisy chained switch is not displayed in the scetch.

 

So what do you think about daisy chaining in general and in this particular scenaro?

Re: Daisy Chaining EX-series switches

$
0
0

Well nobody wants to go multiple levels with switching, but physical connection setups will sometimes demand we have to do so.

 

I assume then the additional downstream switch will come back to a single VC stack which can have the ae bundle as you note for some link redundancy.

 

Since these are VC running ae links, I don't understand what RSTP is doing or why it is needed in this scenario there won't be any blocking ports and all links are in use since there cannot be any loops.

 

Re: Daisy Chaining EX-series switches

$
0
0

Steve,

 

I gues rstp is configured on the distribution and access switches for loop prevention in the case of accidentially faulty coupling of access interfaces. 

 

With regards,

 

Jean

Re: Daisy Chaining EX-series switches

$
0
0

I see the possible benefit of prevention you note in running RSTP for the system.  If the rest of the system is running RSTP then I would also run it on the newly added switches for consistency.

 

It's just my generally preference to avoid enabling protocols that are not needed as a general rule to keep the system free in resources, potential bugs and surface area of attack on the running protocols.

 

Re: Daisy Chaining EX-series switches

$
0
0

Steve,

 

Thank you. 

 

You are stating: "Well nobody wants to go multiple levels with switching",
Why not?

 

Some last qustions about rstp in this matter:

 

What do you think about advising to leave it this way en to additional configure BPDU prevention on all the edge interfaces of all access switches for preventing e.g. (illegal) daisy chaning of some more switches (other than the one legally proposed)?

How about not to configure rstp on the new switch and leave rstp on the original access en distribution switches as is?
Can you prevent the new switch from generating BPDUs by deleting al the entries in the protocols rstp hierarchy?

 

With regards,

 

Jean

Re: Daisy Chaining EX-series switches

$
0
0

I think his comment "Well nobody wants to go multiple levels with switching" is based on the general fact that with multiple levels there are always extra physical hops any communication will encounter, so there will be some added delay, plus more hardware/etc.  In general, for a VC based campus networks traffic is mostly North-South, which means [generally] very little inter-VC traffic.  So most traffic from Access to Core, just hits a Distribution switch, and not another VC switch at the same layer.

 

As for the RSTP/BPDU Block question, you could implement this on the existing Blue VC downward interfaces (but not the AE to the Distribution layer), such that you now control where and who can add an extra [STP enabled] switch.  Yes if you disable/delete RSTP entry for an interface, that interface will not generate BPDUs.

 

One thing not mentioned (I believe) is that if the new switch is of the same model type as the Blue VC (EX model type not mentioned), you could just as easily extend this switch to be part of the Blue VC.  You do this by enabling all the relevant interfaces to run VCPe.  Juniper EX allows VC connectivity over Ethernet, as well as by dedicated VC ports.  This does not solve the "extra layer or multiple levels situation", but does make management of this [previously] standalone switch, be part of the existing VC, instead of by itself.  Maybe a case of 6 of 1, half-a-dozen of the other.

 

Also, I would not refer your topology as Spine-Leaf.  In true Spine-Leaf the Spines are not connected.  Your design is just basic long-time used multilayer with each different layer being a VC.  Again, 6 of 1, half-a-dozen of the other.

 

Good luck.

 

Re: RoCE/DCB/PFC/ETS sample config für QFX5100

$
0
0

Hi vogts,

 

Firstly, RoCE/RDMA suppport per product and Junos can be found here:
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=8593&fn=Remote%20Direct%20Memory%20Access%20(RDMA)%20over%20converged%20Ethernet%20version%202%20(RoCEv2)

 

For QFX, PFC and DCBX configuration can be found here, please also refer the sub-sections:
https://www-origin.junipercloud.net/documentation/en_US/junos/topics/task/configuration/dcbx-mode-configuring-cli.html

 

Here is a good article on DCB and PFC for QFX:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB21938&cat=QFX_SERIES&actp=LIST

 

Attached is a sample config for the config used between 2 juniper switches. This is for QFX3500 and config should be similar for QFX5100 too.  Also attached are some sample DCBX verification commands.

 

Hope this helps.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated Smiley Happy.


Re: RoCE/DCB/PFC/ETS sample config für QFX5100

Q in VNI and overlapping vlans in a evpn/vxlan ip fabric - is this configuration supposed to work?!

$
0
0

Hello, we have bought a few QFX5120 switches, 

Our company is going to offer colocation in our new datacenter, and I intend to use evpn with vxlan in this setup.

I will not route any customer traffic on my switches, because I/they will do all routing externally. 

Therefor, each customer needs to be able to use their own vlans. 

 

I have a spine and leaf topology. I am using eBGP for underlay to distribute loopbacks. I use iBGP in a full mesh between leafes to exchange EVPN information.

 

Take note, I did get evpn with vxlan working when I used regular "trunk" interfaces. However, using that approach, I cannot have overlapping VLANS on the same switch, which I need to work in my colo-case.

 

To my understanding, I need to use encapsulation flexible-ethernet-services, and put every one customer interface in a vlan configuration, with encapsulation vlan-bridge. I understand this as creating seperate bridges for each vlan configuration? Finally I use encapsulate-inner-vlan on the bridge-vxlan config, something like this;

 

 

olof@o12-ls01> show configuration interfaces xe-0/0/7 | display set 
set interfaces xe-0/0/7 description "TEST Customer123"
set interfaces xe-0/0/7 vlan-tagging
set interfaces xe-0/0/7 mtu 9000
set interfaces xe-0/0/7 encapsulation flexible-ethernet-services
set interfaces xe-0/0/7 unit 100 description TEST
set interfaces xe-0/0/7 unit 100 encapsulation vlan-bridge
set interfaces xe-0/0/7 unit 100 vlan-id-list 1-4094

olof@o12-ls01> show configuration vlans Customer123_test | display set 
set vlans Customer123_test interface xe-0/0/7.100
set vlans Customer123_test vxlan vni 200123
set vlans Customer123_test vxlan encapsulate-inner-vlan
set vlans Customer123_test vxlan ingress-node-replication

set protocols evpn encapsulation vxlan
set protocols evpn multicast-mode ingress-replication
set protocols evpn extended-vni-list all
set protocols l2-learning decapsulate-accept-inner-vlan

 

 

 

I do see records in evpn database showing up from my customers, who are sending me vlan tagged frames.

However, they are unable to contact each other.

 

olof@o12-ls01> show evpn database 
Instance: default-switch
VLAN DomainId MAC address Active source Timestamp IP address
200123 00:50:56:a7:52:c1 10.18.255.35 Mar 24 18:08:15 172.18.66.22
200123 00:50:56:a7:56:8b xe-0/0/7.100 Mar 24 18:07:50 172.18.66.14
200123 00:50:56:a7:66:46 xe-0/0/7.100 Mar 24 18:07:49 172.18.66.13

olof@o12-ls01> show ethernet-switching table
...
name address flags interface source
Customer123_test 00:50:56:a7:52:c1 D vtep.32769 10.18.255.35 
Customer123_test 00:50:56:a7:56:8b D xe-0/0/7.100 
Customer123_test 00:50:56:a7:66:46 D xe-0/0/7.100

 

 

 

And this is my system version.

olof@o12-ls01> show version 
...
Hostname: o12-ls01
Model: qfx5120-48y-8c
Junos: 18.3R1.11 flex
JUNOS OS Kernel 64-bit FLEX [20180816.8630ec5_builder_stable_11]

 

 

I used forwarding-options analyzer, but I was only able to see traffic one way. I could see Q in the vxlan packet, which is great, however, no traffic was still being exchanged between hosts. 

 

Re: Q in VNI and overlapping vlans in a evpn/vxlan ip fabric - is this configuration supposed to work?!

$
0
0

I changed my vlan-id-list to NOT include vlan id 1. Now I successfully can ping the other side, with Q in VNI. 

 

olof@o12-ls01# show interfaces xe-0/0/7 | display set
set interfaces xe-0/0/7 vlan-tagging
set interfaces xe-0/0/7 mtu 9000
set interfaces xe-0/0/7 encapsulation flexible-ethernet-services
set interfaces xe-0/0/7 unit 100 encapsulation vlan-bridge
set interfaces xe-0/0/7 unit 100 vlan-id-list 2-4094

leaf switch 2. Just testing slightly different config, but is compatible with above evpn.

olof@o12-ls02# show interfaces xe-0/0/7 | display set
set interfaces xe-0/0/7 flexible-vlan-tagging
set interfaces xe-0/0/7 mtu 9000
set interfaces xe-0/0/7 encapsulation extended-vlan-bridge
set interfaces xe-0/0/7 unit 100 vlan-id-list 2-4094


https://imgur.com/a/rotXxpJ TAG: 0x8100 vlan id 59 - traffic works! 

 

*However* if I include vlan ID 1 in the vlan id list, I somehow get vlan tag 3 in the packets?!, and everything breaks... Im confused? 

https://imgur.com/a/ASVsU77

 

 

Re: Daisy Chaining EX-series switches

$
0
0

As RCCPGM notes, the cascading switch topology just creates more points of failure and additional hops.

 

I like his idea to use the connects to simply add another node as a Virtual Chassis but I'm not sure on the multiple links use case for that.  You mention have a six port ae I'm pretty sure you cannot do that with the VC link.

 

Not sure I follow the RSTP question, but if I understand the concern is people connecting STP enabled switches to the access ports you would need that blocking to occur on all the edge devices.

 

Re: Q in VNI and overlapping vlans in a evpn/vxlan ip fabric - is this configuration supposed to work?!

$
0
0

Hi OlofL,

 

If flexible-vlan-tagging achieves your desired operation, then please its supported configuration is outlined here and the config you have looks alright:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-vxlan-flexible-vlan-tag.html

 

Regarding VLAN 1, please check the VXLAN constraints part for this note:

https://www.juniper.net/documentation/en_US/junos/topics/concept/vxlan-constraints-qfx-series.html

 

"When configuring a VLAN ID for a VXLAN, we strongly recommend using a VLAN ID of 3 or higher. If you use a VLAN ID of 1 or 2, replicated broadcast, multicast, and unknown unicast (BUM) packets for these VXLANs might be untagged, which in turn might result in the packets being dropped by a device that receives the packets."

 

Hope this helps.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated Smiley Happy.

Re: Clean up configuration against actual interfaces - how to

$
0
0

Thank you all for your kind replies !

Re: Virtual Chass - vme0 vs em0

$
0
0

Hi Carlos,

 

Thank you for you reply.

Please disregard the VME interface and groups setup for a moment.

 

Can you let me know if it is normal to see the same IP for both the em0 interfaces across my 2 virtual chassis member ?

 

 

{master:3}
admin@csj1> show virtual-chassis status

Preprovisioned Virtual Chassis
Virtual Chassis ID: 649c.4deb.f522
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    VF3715220163 qfx5100-48s-6q 129   Backup       N  VC   3  vcp-255/0/53
3 (FPC 3)  Prsnt    TA3717210250 qfx5100-48s-6q 129   Master*      N  VC   0  vcp-255/0/53

{master:3}
admin@csj1> show interfaces em0 terse
Interface               Admin Link Proto    Local                 Remote
em0                     up    up
em0.0                   up    up   inet     192.168.0.203/24

{master:3}
admin@csj1> request session member 0

--- JUNOS 17.2R3.4 built 2018-11-16 04:23:49 UTC
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{backup:0}
admin@csj1> show interfaces em0 terse
Interface               Admin Link Proto    Local                 Remote
em0                     up    up
em0.0                   up    up   inet     192.168.0.203/24

{backup:0}

 

Regards,

Alan

 


Re: Virtual Chass - vme0 vs em0

$
0
0

Hi Alan.

 

It is if you have the commit synchronize statement at 

 

{master:1}[edit]
root@4300# show system 

commit synchronize;

so what happens here is that it synchronizes the configuration between the master and backup, in this case that would be expected.

This syncronization is mandatory for HA protocols like GRES, so if you have GRES the best option would be to use a vme.

 

 

 

 

migration ex switches

$
0
0

Hi All,

There is a high number(600) of locations to replace the  new VC EX that consist of a few members. In order to make sure new change doesn't break any part of the network infrastructure, what verification should be done before? And workable ideas, any approaches or any scripting? 

 

Thx

erix

 

Re: Virtual Chassis Monitoring

$
0
0

Thanks, I may look into the syslog aspect of things.  The link however, gives me a 404.

Re: Virtual Chass - vme0 vs em0

$
0
0

Hi Carlos,

 

Thanks for sharing more insights with me.   Yes i am using GRES with commit syncronization.

 

q1) I always thought GRES must be turn on (pre-requisite) to use virtual-chassis.  Did i get it the other way round ?  It seems like GRES is to further compliment virtual-chassis and we can still have a virtual-chassis without GRES ?

 

q2) if i do not have commit-syncronization, does that means i can have technically 2 different configs for the master and backup routing engine ?  (e.g. individual em0 IP set at interface level) - is that allow ?

 

q3) i have ocassionally experience wierd behaviour such that connecitng to my em0 ends me up in the backup member. Could this (commit-syncronise) be the reason ?  (since i have 2 x em0 interface that is setup with the same IP)

 

q4) VME is not included in junos managment instance. So i guess my best chance is to use groups ?

 

Regards,

Alan

 

Re: Virtual Chassis Monitoring

Viewing all 10307 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>