Posted on May 9, 2020 12:47 am
 |  Asked by Sayali Upasani
 |  152 views
RESOLVED
0
0
Print Friendly, PDF & Email

Hey Guys,

I am using Arista 7050sx3 for basic VLAN switching.

I have multiple access ports with multiple VLANs. There is one port-channel (consisting of two ethernet interfaces) going to a Juniper router for inter-vlan routing.

I just wanted to confirm what configurations do I need on port-channel going to my router apart from configuring it as trunk switchport mode trunk and specifying allowed vlans.

My current setup is not working.. just wondering if there is any other specific encapsulation command to be enabled for this to work.

Thanks,

Sayali

0
Posted by Stuti Gor
Answered on May 9, 2020 1:43 am

Hello Sayali,

For basic L2 forwarding, the below two commands should be enough.

switchport mode trunk
switchport allowed vlan 1,,

Can we confirm if the port-channel has active ports on it? Also you can check the output of #show vlan to confirm if Port-channel is a part of those vlans.

Do we see the MAC address of the Juniper device getting learnt on the port-channel of Arista under #show mac-address table?

0
Posted by Aniket Bhowmick
Answered on May 9, 2020 6:26 am

Hi Sayali,

Please follow the below steps one by one:

  • Check if the port-channel is up or not: "show interfaces port-Channel <id>"
  • If the port-channel is up, make sure all Vlan is present on the port-channel: "show vlan"
  • If the concerned Vlan is present, check the Spanning-tree status: show spanning-tree
  • If it is RPVST, check if the port-channel is in "forwarding state" in all the concerned Vlans
  • If it is MSTP, check if the port-channel is in "forwarding-state" in the instance which includes your concerned Vlans.
  • Also check the Spanning-tree status on Juniper side as well.

It might be possible that the Arista switch is forwarding the traffic out of the port-channel and getting dropped on the other side. You can confirm if Arista is forwarding the traffic or not using Outbound ACL Counters on the port-channel. See the below example:

Consider the port-channel is Po9 and the source-IP is 1.1.1.1 and destination IP is 2.2.2.2. Create the ACL as below:

ip access-list test
statistics per-entry
10 permit ip host 1.1.1.1 host 2.2.2.2
20 permit ip any any

^ Now apply this ACL on the Po9 (which connects to Juniper) in the outbound direction:

interface Port-Channel9
switchport mode trunk
ip access-group test out

Now, check the ACL counter as below:

#show ip access-lists test
IP Access List test
statistics per-entry
10 permit ip host 1.1.1.1 host 2.2.2.2.  [match 10 packets, 0:05:49 ago]
20 permit ip any any.                              [match 15682 packets, 0:00:00 ago]

^ As you can see in this case, the counter for the flow (Source-1.1.1.1, destination-2.2.2.2) is incrementing which proves packets are getting forwarded out of port-channel9. If it doesn't increment, then it means it is getting dropped on Arista for some reason (which we need to check).

Note: The IP ACL test is useless if ARP is not resolved on Source host (either for it's GW or of another host in same Vlan it is trying to ping). In that case, make sure to configure a static ARP on the source host. If static ARP cannot be programmed, then instead of IP ACL test, we need to do MAC ACL test. Let us know if you need help with that. Also ensure Source host is actually sending traffic.

Regards,

Aniket

0
Posted by Sayali Upasani
Answered on May 11, 2020 5:38 pm

Thank you everyone!

Apparently, the problem was somewhere else but it was good to know that I did not miss any simple configuration on Arista that caused inter-vlan routing to fail.

Also, since Arista does not capture packets that are simply switched, the idea of creating ACLs by Aniket was something I desperately needed!

Thanks again!

Cheers,

Sayali

0
Posted by Aniket Bhowmick
Answered on May 12, 2020 12:57 am

Hi Sayali,

Just wanted to let you know, Arista has the following platforms where you can capture packets that are switched/routed in Hardware by mirroring them to CPU, like: 7280R Series, 7500R series, 7020R series, 7160 series and 7150 series

7050 and 7060 series didn't have the mirroring to CPU support for quite some time. But now since the release of EOS-4.24.0F version (and later versions), even these two series (along with few others which didn't have the support before) supports packet mirroring to CPU. Please see the following TOI: Mirror to CPU on 7060 & 7050

Using the feature- "Mirroring to CPU" you can mirror any packet, that is getting switched or routed in the Hardware, to the CPU and capture those packets in the CPU itself. Generally packets that are switched/routed in Hardware will not go to the CPU. It is a great tool for troubleshooting and inspection of packets in the network.

Since issue is resolved we will close this thread.

Thanks !
Aniket

Post your Answer

You must be logged in to post an answer.