Ethernet Switching
Ethernet Switching

Issues with IRB and trunk

2 weeks ago

Hello 

 

I am new to Juniper and trying to do a simple thing which isn't working for me. 

 

I have goe two EX4300 switches linked via LACP ether-channel (ae0) I have created IRBs on each switch and trying to ping IP address of one from the other and it is not working.

 

I have got following configuration

 

SWITCH 1

 

set interfaces irb unit 100 family inet address 172.16.1.2/24
set interfaces irb unit 110 family inet address 172.16.2.2/24
set interfaces irb unit 120 family inet address 172.16.3.2/24
set interfaces irb unit 130 family inet address 172.16.4.2/24

set vlans Test1 vlan-id 100
set vlans Test1 l3-interface irb.100
set vlans Test2 vlan-id 110
set vlans Test2 l3-interface irb.110
set vlans Test3 vlan-id 130
set vlans Test3 l3-interface irb.130
set vlans Test4 vlan-id 120
set vlans Test4 l3-interface irb.120

set interfaces ae0 vlan-tagging
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members Test1
set interfaces ae0 unit 0 family ethernet-switching vlan members Test2
set interfaces ae0 unit 0 family ethernet-switching vlan members Test3
set interfaces ae0 unit 0 family ethernet-switching vlan members Test4

 

Switch 2

set interfaces irb unit 100 family inet address 172.16.1.1/24

set vlans Test1 vlan-id 100
set vlans Test1 l3-interface irb.100
set vlans Test2 vlan-id 110
set vlans Test3 vlan-id 130
set vlans Test4 vlan-id 120

set interfaces ae0 vlan-tagging
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members Test1
set interfaces ae0 unit 0 family ethernet-switching vlan members Test2
set interfaces ae0 unit 0 family ethernet-switching vlan members Test3
set interfaces ae0 unit 0 family ethernet-switching vlan members Test4

Now if from switch  I try to ping 172.16.1.1 the ping fails and 100% of packets are lost.

 

I have looked at "show interface terse" on both switches and ae0 and irb 100 are up. And "show vlan brief" shows that all vlans are active on ae0.

 

I hope someone can help me with this.

 

Thanks

 

 

10 REPLIES 10
Ethernet Switching

Re: Issues with IRB and trunk

2 weeks ago
Hi Jam,

To begin with,Can you check if you are able to learn the mac address on the ae0 interface

show ethernet-switching table

Also could you please provide the output of arp from both switches

Show arp no-resolve

Regards,
Jibu
Ethernet Switching

Re: Issues with IRB and trunk

2 weeks ago

Hi,

 

I think we are quite close to make it work since you already got you ae bundle and irb up.

 

Let's check a few more things:

1. Is arp learned? "show arp no-resolve |match irb"

2. Use the source of irb interface to ping. For example "ping 

ping 172.16.1.2 source 172.16.1.1  

3. On some EX serials switch, the L3 interface is vlan.xxx. Check if this is your case 

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

 


Mengzhe Hu
JNCIE x 3 (SP DC ENT)
Ethernet Switching

Re: Issues with IRB and trunk

2 weeks ago

Hi,

 

The config looks good. Are some IPs responding to the ping, can you try using the source and monitor the interface (monitor traffic interface irb.100)? did it work at any point? Maybe this could be related:

 

[EX] Adding a second IRB to an AE and removing it causes the first IRB to stop working on EX4300 running Junos OS 17.3R3.10+

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

Ethernet Switching

Re: Issues with IRB and trunk

a week ago

Hello

 

 I am not getting any arp entries. I rebooted both switches and then after trying unsuccessful ping looked for the arp entries and there were none

 

SWITCH 1

 

 

ping 172.16.1.1 source 172.16.1.2
PING 172.16.1.1 (172.16.1.1): 56 data bytes
^C
--- 172.16.1.1 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

 

 

 

 

root@Access-Stack> show arp no-resolve | match irb
show interfaces ae0 terse
Interface               Admin Link Proto    Local                 Remote
ae0                     up    up
ae0.0                   up    up   eth-switch
ae0.32767               up    up

 

 

 

 show interfaces irb terse
Interface               Admin Link Proto    Local                 Remote
irb                     up    up
irb.0                   up    down inet
irb.10                  up    down inet     172.16.0.2/24
irb.100                 up    up   inet     172.16.1.2/24
irb.110                 up    up   inet     172.16.2.2/24
irb.120                 up    up   inet     172.16.3.2/24
irb.130                 up    up   inet     172.16.4.2/24
irb.220                 up    down inet

SWITCH 2

 

 

> ping 172.16.1.2 source 172.16.1.1
PING 172.16.1.2 (172.16.1.2): 56 data bytes
^C
--- 172.16.1.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

 

 

 

show arp no-resolve | match irb

 

 

show interfaces irb terse
Interface               Admin Link Proto    Local                 Remote
irb                     up    up
irb.100                 up    up   inet     172.16.1.1/24
irb.220                 up    down inet
 show interfaces ae0 terse
Interface               Admin Link Proto    Local                 Remote
ae0                     up    up
ae0.0                   up    up   eth-switch
ae0.32767               up    up

 

I started of something quite ambititious and setup Virtual Router configuration and tried to configure sub-interfaces on ae0 with each sub-interface in each Virtual router instance. When that didn't work as I then tried to implement something simple and then try more complex setup. But now even simple trunk configuration isn't working.

 

Thanks 

 

Thanks

 

 

 

Ethernet Switching

Re: Issues with IRB and trunk

a week ago
Can you provide the output of the below from both the switch while the ping is going on

show ethernet-switching table
show route

Also can you paste the output of while doing a ping

monitor traffic interface irb.100 <<<. From both the switch



Regards,
Jibu
Ethernet Switching

Re: Issues with IRB and trunk

a week ago

Hello

 

I have the follwong output

 

Sending Switch

 

show ethernet-switching table

show route

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 06:20:19
                    > to 10.50.130.254 via vme.0
10.50.130.0/24     *[Direct/0] 06:20:19
                    > via vme.0
10.50.130.250/32   *[Local/0] 06:20:19
                      Local via vme.0
172.16.0.2/32      *[Local/0] 06:20:20
                      Reject
172.16.1.0/24      *[Direct/0] 06:17:54
                    > via irb.100
172.16.1.2/32      *[Local/0] 06:20:19
                      Local via irb.100
172.16.2.0/24      *[Direct/0] 06:17:54
                    > via irb.110
172.16.2.2/32      *[Local/0] 06:20:19
                      Local via irb.110
172.16.3.0/24      *[Direct/0] 06:17:54
                    > via irb.120
172.16.3.2/32      *[Local/0] 06:20:19
                      Local via irb.120
172.16.4.0/24      *[Direct/0] 06:17:54
                    > via irb.130
172.16.4.2/32      *[Local/0] 06:20:19
                      Local via irb.130



monitor traffic interface irb.100
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on irb.100, capture size 96 bytes

Reverse lookup for 172.16.1.1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

04:22:53.734501 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:54.434502 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:55.238670 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:56.038501 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:56.738494 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:57.638495 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:58.338496 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:59.243662 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:22:59.843496 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:23:00.543496 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:23:01.143495 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:23:01.943496 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:23:03.248018 Out arp who-has 172.16.1.1 tell 172.16.1.2
04:23:03.847498 Out arp who-has 172.16.1.1 tell 172.16.1.2
^C
14 packets received by filter
0 packets dropped by kernel

Receiving Switch

root@Access-Stack> monitor traffic interface irb.100
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on irb.100, capture size 96 bytes

^C
0 packets received by filter
0 packets dropped by kernel

Lldp output to confirm I ahve got the right ports

@Access-Stack> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
me0                -                   c0:bf:a7:76:94:00   ge-2/0/38          R3-VC-EX-U
ge-0/0/47          ae0                 cc:e1:94:e3:a3:40   ge-0/0/44          ClientNetwork
ge-1/0/47          ae0                 cc:e1:94:e3:a3:40   ge-0/0/46          ClientNetwork



@ClientNetwork> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
me0                -                   c0:bf:a7:76:94:00   ge-2/0/39          R3-VC-EX-U
ge-0/0/44          ae0                 cc:e1:94:e3:d6:40   ge-0/0/47          Access-Stack
ge-0/0/46          ae0                 cc:e1:94:e3:d6:40   ge-1/0/47          Access-Stack

Thanks

Ethernet Switching

Re: Issues with IRB and trunk

a week ago

Are they directly connected? Is this on a lab enviroment, if so will you be able to try with a single trunk link instead of an ae?

Ethernet Switching

Re: Issues with IRB and trunk

a week ago

These Switches are directly conneced and being used for testing. I tried two differnt ports. First tried them as access ports in VLAN 100 and ping worked. created a simplest trunk on both ends. 

 

set interfaces <interface> unit 0 family ethernet-switching interface-mode trunk
set interfaces <interface> unit 0 family ethernet-switching vlan members all

Nothing else under the interface configuration. As soon as I move the configuration to trunk the ping stops working. Also tried the aeo port as access ports and that works too. It is onl when I create a trunk beween the two switches it stops working.

 

Thanks

 

Ethernet Switching

Re: Issues with IRB and trunk

yesterday

Hi,

 

configure this command 

set chassis aggregated-devices ethernet device-count 10 and then commit

Under both the ae0 configuration please remove "vlan-tagging". this is not needed.

 

run "show ethernet-switching interface ae0"  command and check if all the VLANs defined under ae0 is tagged and then if the port is in forwarding state.

 

Also run CLI command " show lacp interfaces ae0" to see if the state is "collecting and distributing"

 

Run CLI command "show ethernet-switching table interface ae0" to check mac table is populated.

Check CLI command "show arp no-resolve" and verify if ARP is resolved.

 

Once all the above verification  is done. Ping should work, if not create JTAC case.

Ethernet Switching
Solution
Accepted by topic author jam
an hour ago

Re: Issues with IRB and trunk

an hour ago

I eventually founf ou what the problem was. It was this statement

 

set interfaces ae0 vlan-tagging

So my investigation is shown that if you add vlan tagging to a interface where you create a trunk it somwhow corrupts the vlan in a way that it can't be trunked anymore. Not even vlan-tagging command is removed. As I tested that. If you create a new vlan after that it works and also if you delete the old vlan and recreate the same vlan it starts working. I believe it is a bug here.

 

If vlan-tagging is not acceptable with a trunk then it should not et me commit

secondly after removing vlan-tagging it should revert back to as it was.