I tried it and gave up and used the following.
forwarding-options {
helpers {
bootp {
relay-agent-option;
server 10.127.199.13;
interface {
irb.200;
irb.205;
irb.199;
Thanks for the sharing the requested output. the reason you dont get those command is due to Next-Gen Routing-Engine (RE-S-EX9200-2X00x6), thus, you will Not see request system power off/on or halt.
They are replaced with "request vmhost" commands.
Use this command "request vmhost power-off".
:/ So it didn't work for you either? This is pretty disasterous...
Thanks Karand, indeed that is it.
test@ex9204-core2-re0> request vmhost ? Possible completions: cleanup RE vmhost cleanup /var/tmp, /var/crash and /var/log file-copy Copy file from vmhost to vjunos halt Halt the software on RE hard-disk-test Run smartd self tests on hard disks power-off Power off the software on RE power-on Power on the system reboot Reboot RE vmhost snapshot Create a vmhost recovery snapshot software Perform vmhost software extension or upgrade zeroize Erase all data, including configuration and log files
What release are you running? Would suggest to create a case and have JTAC take a look.
Hi rtrabelsi,
i am getting the same problem. did you manage to get your xe- interfaces? if yes, then please share your solution. Thanks
Regards
Badar
16.1R6-S2.3
That would be the next step. I'm not generally the type to just go to support for everything, but when it seems to be an issue, that is where i go.
I tested this, quite sometime back, may be 14.x release. Here are the result, unfortunately don't have a setup for quick test now..
{master}[edit]
root@MX104-1# show bridge-domains bd1100
vlan-id 1100;
interface ge-1/1/2.1100;
routing-interface irb.1100;
forwarding-options {
dhcp-security {
arp-inspection;
ip-source-guard;
}
}
{master}[edit]
root@MX104-1# show interfaces ge-1/1/2.1100
encapsulation vlan-bridge;
vlan-id 1100;
{master}[edit]
root@MX104-1# show interfaces irb.1100
family inet {
address 192.0.1.254/24;
}
mac fa:ae:aa:cd:fb:ab;
{master}[edit]
root@MX104-1# show forwarding-options dhcp-relay
server-group {
AMIT_DHCP {
135.1.0.2;
}
}
group AMIT_DHCP {
active-server-group AMIT_DHCP;
interface irb.1100;
}
{master}[edit]
root@MX104-1#
{master}[edit]
root@MX104-1# run show dhcp relay binding detail
Client IP Address: 192.0.1.11
Hardware Address: 00:10:65:31:01:02
State: BOUND(RELAY_STATE_BOUND)
Lease Expires: 2018-03-15 15:32:36 UTC
Lease Expires in: 3446 seconds
Lease Start: 2018-03-15 14:32:36 UTC
Last Packet Received: 2018-03-15 14:32:36 UTC
Incoming Client Interface: irb.1100:ge-1/1/2.1100
Server Ip Address: 135.1.0.2
Server Interface: none
Bootp Relay Address: 192.0.1.254
Session Id: 21
Client IP Address: 192.0.1.10
Hardware Address: 00:10:65:31:01:03
State: BOUND(RELAY_STATE_BOUND)
Lease Expires: 2018-03-15 15:32:36 UTC
Lease Expires in: 3446 seconds
Lease Start: 2018-03-15 14:32:36 UTC
Last Packet Received: 2018-03-15 14:32:36 UTC
Incoming Client Interface: irb.1100:ge-1/1/2.1100
Server Ip Address: 135.1.0.2
Server Interface: none
Bootp Relay Address: 192.0.1.254
Session Id: 20
Client IP Address: 192.0.1.12
Hardware Address: 00:11:64:31:01:02
State: BOUND(RELAY_STATE_BOUND)
Lease Expires: 2018-03-15 15:30:08 UTC
Lease Expires in: 3298 seconds
Lease Start: 2018-03-15 14:30:08 UTC
Last Packet Received: 2018-03-15 14:30:08 UTC
Incoming Client Interface: irb.1100:ge-1/1/2.1100
Server Ip Address: 135.1.0.2
Server Interface: none
Bootp Relay Address: 192.0.1.254
Session Id: 19
{master}[edit]
root@MX104-1# run show dhcp-security binding ip-source-guard
IP address MAC address Vlan Expires State Interface
192.0.1.10 00:10:65:31:01:03 bd1100 3437 BOUND ge-1/1/2.1100
192.0.1.11 00:10:65:31:01:02 bd1100 3437 BOUND ge-1/1/2.1100
192.0.1.12 00:11:64:31:01:02 bd1100 3290 BOUND ge-1/1/2.1100
192.0.1.13 00:10:65:31:01:02 bd1100 2856 BOUND ge-1/1/2.1100
{master}[edit]
root@MX104-1#
This is dhcp-relay.. though, not actually dhcp-snooping it could work. I would have to make a few changes to my setup. Real dhcp-snooping should operate with the dhcp server and the dhcp clients in the same vlan. But thank you for the example. Trying dhcp-relay was my next "fix" for the shortcoming.
Maybe a better way to approach your situation is to tell us what you are trying to accomplish, not what you are trying to configure - yes?
In meantime, I will try to do some checking on Port-Level security features on MX. BTW, what exact MX HW and SW are you using? This could well be related to what you are seeing. For example, IF Port-Level security features are support on MX, there would 1) need to min SW level (looks like 14.1R1 except for latest MX models) and 2) I doubt very much this support is there on say DPC modules.
I will do my best to explain better. I am trying to accomplish dhcp snooping.
More details are... I need clients that are on multiple layer 2 domains (vlans, bridge-domains, etc) to be able to get ip addressing via dhcp servers on those networks, but not be able to become dhcp servers on those networks. This is what dhcp-snooping is for. Generally you have a vlan which has dhcp snooping enabled. Then you have a trusted dhcp server, or a list of trusted dhcp servers. And you almost always have a port or list of ports that are trusted for dhcp snooping, all other ports on that vlan are considered "untrusted" and cannot home dhcp servers.
This is not to be confused with dhcp relay which takes dhcp broadcasts and forwards them as unicast to a server which is not on the same layer 2 domain. (dhcp relay is intended to overcome the issue of having an offsite (not on the same lan segment) dhcp server where the broadcasts from the intended network cannot reach)
More information is listed in the juniper documentation, and the part I am facing is the portion anchored at the top as "DHCP Server Access" > "Switching Device, DHCP Clients, and DHCP Server Are All on the Same VLAN". Here is the doc:
https://www.juniper.net/documentation/en_US/junos/topics/concept/port-security-dhcp-snooping.html
Cisco does this, brocade does this, HP/Aruba does this, Fortinet, Adtran... I would be amazed if i cannot do this on a Juniper MX. I just cannot figure out where this is going wrong.
Now, I am not above doing this with dhcp relay if I must, but I am more concerned that my "rogue" test dhcp server is able to serve clients even when i have both interfaces set to "override untrusted" in the MX...
{master}[edit bridge-domains vlan-1002]
forwarding-options {
dhcp-security {
arp-inspection;
ip-source-guard;
group TEST {
overrides {
untrusted;
}
interface ge-4/0/0.0;
}
group untrust {
overrides {
untrusted;
}
interface xe-0/1/0.1002;
}
option-82 {
circuit-id;
}
}
}(please note, the "option-82 circuit-id" portion is simply to try to get dhcp snooping working as stated in the documention)
Description
Configure port security features on the switching device. DHCP snooping is enabled automatically if you configure any of the following port security features within this hierarchy:
Dynamic ARP inspection (DAI)
IP source guard
DHCP option 82
Static IP
The remaining statements are explained separately. See CLI Explorer.But no matter what i enable, i see no results in show dhcp-security <anything at all>. Just blank. This is where I believe there must be a misconfiguration. If I had any bindings at all, or even any statistics, then I would be able to say "it doesnt work" or "I missed this part" or "This is working" or "Juniper MX cannot do this". But with blank information in the output, there must be something missing.
Here is my current state:
ge-4/0/0 is the interface facing my dhcp client. xe-0/1/0.1002 is the interface facing my dhcp server. bridge-domains match vlan IDs. Untagged interface to the client, tagged interface to the server, but trusted has been "overridden" per documentation to untrust. DHCP should NOT work at this point, if configured right. I set the lease time on the dhcp server to 60 seconds for testing.
re0> show configuration interfaces ge-4/0/0
unit 0 {
family bridge {
interface-mode access;
vlan-id 1002;
}
}
re0> show configuration interfaces xe-0/1/0
description "vlan 1002 to dhcp server";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
.
.
.
unit 1002 {
encapsulation vlan-bridge;
vlan-id 1002;
}
.
.
.
re0> show configuration bridge-domains vlan-1002
description test-dhcp-snooping;
vlan-id 1002;
interface xe-0/1/0.1002;
interface xe-1/1/0.1002;
routing-interface irb.1002;
forwarding-options {
dhcp-security {
arp-inspection;
group TEST {
overrides {
untrusted;
}
interface xe-0/1/0.1002;
interface ge-4/0/0.0;
}
option-82 {
circuit-id;
}
}
}
re0> show dhcp-security arp inspection statistics
{master}
re0> show dhcp-security arp inspection statistics
{master}
re0> show dhcp-security binding
{master}
re0> show dhcp-security statistics
DHCP messages:
-------------
Total 0
Discover 0
Offer 0
Request 0
Decline 0
Ack 0
Nack 0
Release 0
Inform 0
Force renew 0
Renew 0
Rebind 0
Packets dropped:
---------------
Total 0
No configuration 0
No VLAN 0
No interface 0
Request on trusted port 0
{master}
I hope this is enough information and better explains what I am trying to accomplish, and likewise, what I have had running and in place for years on other vendor equipment.
I left out the software and hardware, I apologize.
re0> show version
Hostname: MX480re0
Model: mx480
Junos: 16.1R6-S2.3
I am running RE-S-1800x4, 2 of them
2 x DPCE 4x 10GE R
1 x DPCE 40x 1GE R
If this is "unsupported" on these cards, shouldn't that be documented somewhere?
Thanks, Wojtek, for your suggestion.
I did put that config in place, but am still seeing packet drops therefater...
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
Queued:
Transmitted:
Packets : 12141436
Bytes : 11219662343
Tail-dropped packets : 30884
RL-dropped packets : 0
RL-dropped bytes : 0(perhaps not as many as before, but still...)
How about replacing congested link with two configured as aggregate ethernet? Is it an option? Do you have spare interfaces you could use?
Regards, Wojtek
Do you monitor the interface bandwidth and can confirm that this is not simply exceeding the port capacity?
Or exceeding the maximum throughput overall for you model of SRX?
Could you explain what you mean by setting the write MAC address. My show interface are sowing MAC address for all xe interfaces on vmware, I am just not sure how to conenect vqfx's router via xe interfaces and be able to ping. I apriciate it f you could explain this to me.
root@vqfx-re# run show interfaces xe-0/0/1
Physical interface: xe-0/0/1, Enabled, Physical link is Up
Interface index: 649, SNMP ifIndex: 512
Link-level type: Ethernet, MTU: 1518, LAN-PHY mode, Speed: 10Gbps, Duplex: Full-Duplex, BPDU Error: None, Loop Detect PDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Disabled, Media type: Fiber
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
CoS queues : 8 supported, 8 maximum usable queues
Current address: 02:05:86:71:53:07, Hardware address: 02:05:86:71:53:07
Last flapped : 2018-03-15 14:29:26 UTC (1d 22:20 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Active alarms : None
Active defects : None
Interface transmit statistics: Disabled
Yes, this should be, and I will look into this. In the meanwhile I am 99% sure this functionality is NOT supported on older DPCE modules, only newer MPC. I will check is there is any limitation on the various MPC models, as well.
Regards
Having some issues with a very simple Lab scenario between an EX2200-C and a Cat 3560. Both devices are basically in default configuration. The Juniper has the configuration listed below and the topology is listed below that. My issue is that when I have the Catalyst with no LAG/Etherchannel configuration I end up getting a Layer 2 loop. It seems that the member interfaces on the Juniper are still forwarding traffic even though the Aggregated interface is down. I'm used to seeing the Cisco devices put the interfaces into an individual state and keep them running in STP to prevent loops.
Is this behavior normal?
---- Notes 1: This is a lab test environment Notes 2: You shouldn't have one end not configured for LAG but this is a test to see what happens in that case
Notes 3: I'm trying to simulate the scenario where one party provisions a LAG before the other
EX2200-C is running: 12.3R12 ############################################################################ Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/1/1.0 128:562 128:562 32768.3c61046021c1 20000 FWD DESG {master:0} ############################################################################ root> show configuration chassis aggregated-devices { ethernet { device-count 1; } } root# show interfaces ge-0/0/0 ether-options { speed { 100m; } 802.3ad ae0; } root# show interfaces ge-0/0/01 ether-options { speed { 100m; } 802.3ad ae0; } root# show interfaces ae0 description "Link to DSW1"; aggregated-ether-options { lacp { active; } } unit 0 { family ethernet-switching; } ############################################################################ LAG +--+ | | +---------------------------------------------+ |---------------------------------------------| || | | || || +--+ || || || ge-0/0/1||ge-0/0/1 ||f0/1 +--------------+ +--------------+ | | | | | EX-2200C |ge-0/1/1 g0/1| c3560 | | +-------------------------+ | | | | | +--------------+ +--------------+
#############################################################################