Subject: RARE user and assistance email list
List archive
- From: mc36 <>
- To: Maria Del Carmen Misa Moreira <>, "" <>, Xavier Jeannin <>
- Subject: Re: [RARE-users] [freertr] Test 3: Layer 2 - Abstract from Layer 3
- Date: Wed, 23 Feb 2022 08:38:18 +0100
hi,
i did a quick labbing on your setup and imho it's the only thing we can do on
bridges right now:
sid#show config-differences
access-list asdf
sequence 10 permit all any all any all flow 1111
sequence 20 permit all any all any all flow 2222
sequence 30 permit all any all any all flow 3333
sequence 40 permit all any all any all
exit
bridge 666
mac-learn
exit
interface bvi666
no description
no shutdown
no log-link-change
exit
interface pwether0
no description
mtu 1500
macaddr 006f.0204.1261
pseudowire v1 loopback0 pckoudp 10.5.255.1 30042
no shutdown
no log-link-change
exit
interface pwether1
no description
mtu 1500
macaddr 0004.2069.1477
vrf forwarding v3
ipv4 address 1.1.1.2 255.255.255.0
ipv6 address 1234::2 ffff:ffff:ffff:ffff::
pseudowire v1 loopback0 pckoudp 10.5.255.1 30043
no shutdown
no log-link-change
exit
interface pwether2
no description
mtu 1500
macaddr 0042.2c17.3a0a
vrf forwarding v4
ipv4 address 1.1.1.6 255.255.255.0
ipv6 address 1234::3 ffff:ffff:ffff:ffff::
pseudowire v1 loopback0 pckoudp 10.5.255.1 30044
no shutdown
no log-link-change
exit
interface pwether3
no description
mtu 1500
macaddr 0001.7e46.742a
vrf forwarding v5
ipv4 address 1.1.1.10 255.255.255.0
ipv6 address 1234::4 ffff:ffff:ffff:ffff::
pseudowire v1 loopback0 pckoudp 10.5.255.1 30045
no shutdown
no log-link-change
exit
interface pwether4
no description
mtu 1500
macaddr 0077.2e55.3c05
pseudowire v1 loopback0 pckoudp 10.5.255.1 30046
no shutdown
no log-link-change
exit
interface sdn1
no description
mtu 1500
macaddr 002f.1449.3218
bridge-group 666
no shutdown
no log-link-change
exit
interface sdn2
no description
mtu 1500
macaddr 0012.2477.6a69
bridge-group 666
bridge-filter ipv6in asdf
no shutdown
no log-link-change
exit
interface sdn3
no description
mtu 1500
macaddr 0029.0d74.2338
bridge-group 666
no shutdown
no log-link-change
exit
interface sdn4
no description
mtu 1500
macaddr 0046.5932.7d12
bridge-group 666
no shutdown
no log-link-change
exit
server p4lang p4
export-bridge 666
export-port sdn1 1 0 0 0 0
export-port sdn2 2 0 0 0 0
export-port sdn3 3 0 0 0 0
export-port sdn4 4 0 0 0 0
interconnect pwether0
vrf v1
exit
sid#
here sdnX is the port on the dataplane vm, and pwetherX is the faceplate port
taken from qemu...
just forget about the pwetherX here, they're here to test out the
configuration... only look at
sdnX, the p4lang and the acl... first of all, your tofino should have the
bridge and acl enabled:
sid#show p4lang p4
category value
peer 10.5.122.126
closed 0
capability bridge copp inacl outacl tun gre tap
platform tna/bfforwarder
since 2022-02-23 08:28:14
for 00:05:24
sid#
after that, you should have the sw+hw notation around the mac addresses:
sid#show bridge 666
packet byte
iface fwd phys tx rx drop tx rx drop grp
bvi true true 0 0 0 0 0 0
sdn1 true true 28 12 0 2030 796 0
sdn2 true true 24 16 0 1702 1124 0
sdn3 true true 25 14 0 1776 1002 0
sdn4 true true 35 0 0 2586 0 0
packet byte
addr iface static time tx rx drop tx rx
drop
0001.7e46.742a sdn3 false 00:00:45 2+0 14+11 0+0 96+0
1002+1034 0+0
0004.2069.1477 sdn1 false 00:00:45 2+137 12+146 0+0 96+11234
796+12056 0+0
0042.2c17.3a0a sdn2 false 00:00:45 3+138 16+149 0+0 144+11324
1124+12358 0+0
sid#
after basic testing, i did a ping like this:
sid#ping 1234::2 /vrf v4 /flow 2222 /repeat 123
pinging 1234::2, src=null, vrf=v4, cnt=123, len=64, tim=1000, gap=0, ttl=255,
tos=0, sgt=0, flow=2222, fill=0, sweep=false, multi=false, detail=false
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!debug
servP4lang.sendLine:servP4lang.java:663 tx: keepalive
!!!!!!!!!!!!!!!!!!!!!
result=100%, recv/sent/lost/err=123/123/0/0, rtt
min/avg/max/sum=12/13/20/1708, ttl min/avg/max=255/255/255
sid#
then you can see the acl hit count populated on sequence 20 with the 123 hw
matched packets:
sid#show access-list asdf
sequence 10 permit all any all any all flow 1111
match=tx=0+0(0+0) rx=0+0(0+0) drp=0+0(0+0) accessed=never ago, 00:00:00
timeout
sequence 20 permit all any all any all flow 2222
match=tx=0+0(0+0) rx=0+10086(0+123) drp=0+0(0+0) accessed=00:03:48 ago,
00:00:00 timeout
sequence 30 permit all any all any all flow 3333
match=tx=0+0(0+0) rx=0+0(0+0) drp=0+0(0+0) accessed=never ago, 00:00:00
timeout
sequence 40 permit all any all any all
match=tx=0+0(0+0) rx=496+1014(6+11) drp=0+0(0+0) accessed=00:01:17 ago,
00:00:00 timeout
sid#
just to count the different classes, it should be enough...
but ask your supervisor if the wedge could participate in the bgp...
they still can route around in case of the wedge fails, but the
wedge could do much more on routed ports....
regards,
cs
On 2/21/22 17:09, mc36 wrote:
and more importantly, this is how
http://sources.nop.hu/cfg/p4lang-rout006.tst looks on an emulated tofino:
r1#show interfaces summary
interface state tx rx drop
loopback0 up 460 0 0
loopback9 up 0 0 0
bvi1 up 0 576 576
ethernet1 up 84032 104938 0
ethernet2 up 6276 4180 0
sdn1 up 4780+5214 3354+5382 0+0
sdn1.111 up 4508+0 3162+4058 0+0
sdn2 up 456+8840 252+9074 0+0
sdn2.111 up 428+8944 236+8760 0+0
sdn3 up 408+2526452 252+2526514 0+0
sdn3.111 up 384+2542188 236+2526200 0+0
sdn4 up 456+2526538 204+2526428 0+0
sdn4.111 up 428+2542210 192+2526114 0+0
^^^^^^^^^^ ^^^^^^^^^^^ the hw
counters!!!!
r1#show bridge 1
packet byte
iface fwd phys tx rx drop tx rx drop grp
bvi true true 0 0 0 0 0 0
sdn2.111 true true 7 4 0 428 236 0
sdn3.111 true true 6 4 0 384 236 0
sdn4.111 true true 7 3 0 428 192 0
packet
byte
addr iface static time tx
rx drop tx rx drop
0000.0000.4444 sdn2.111 false 00:00:31 2+96 4+101 0+0
88+8272 236+8696 0+0
0000.0000.5555 sdn3.111 false 00:00:00 0+2320 4+2322 0+0
0+2525948 236+2526136 0+0
0000.0000.6666 sdn4.111 false 00:00:00 0+2320 3+2321 0+0
0+2525970 192+2526050 0+0
^^^^^^^ ^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^
the hw counters!!!!
r1#
On 2/21/22 16:58, mc36 wrote:
anyway, frederic just added the acl counter reporting, this is what i see
when i ran
java -Xmx512m -jar rtr.jar test tester p4lang-acl05 other p4lang301.ini wait
which executed http://sources.nop.hu/cfg/crypt-acl05.tst with an emulated
tofino:
r1#show access-list test4
sequence 10 deny 1 2.2.2.104 255.255.255.255 all 2.2.2.106
255.255.255.255 all
match=tx=0+0(0+0) rx=0+860(0+10) drp=0+0(0+0) accessed=00:00:58 ago,
00:00:00 timeout
sequence 20 permit all any all any all
match=tx=0+0(0+0) rx=1216+1264697(19+1180) drp=0+0(0+0)
accessed=00:00:29 ago, 00:00:00 timeout
r1#show access-list test6
sequence 10 deny 58 4321::104 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
4321::106 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
match=tx=0+0(0+0) rx=0+860(0+10) drp=0+0(0+0) accessed=00:01:07 ago,
00:00:00 timeout
sequence 20 permit all any all any all
match=tx=0+0(0+0) rx=1544+1265113(23+1184) drp=0+0(0+0)
accessed=00:00:07 ago, 00:00:00 timeout
^^^^^^^^^^ ^^^^^^
these are the reported hw counters!!!!
r1#
On 2/21/22 16:14, mc36 wrote:
hi,
imho the issue is that your switch is still in the p4lab profile which does
not have bridging support in the tofino.bin...
first of all, try to switch the profile somehow (alex will tell you how to do
that on your version) hten start with the
bare minimum:
bridge 1
mac-le
int sdn1.1001
bridge-gr 1
int sdn7.1001
bridge-gr 1
and check if the mac table is populated, and the sw+hw notation of counters
appear...
this one is particularly important because in your current setup i only saw
sw counters in the morning...
then if you reached that state, you could add the counting acls, one per
subinterface....
regards,
cs
On 2/21/22 12:15, Maria Del Carmen Misa Moreira wrote:
Hi Csaba,
I'm testing things and keep learning, I will explain you something that I'm
seeing...
1. If I have 'interface bvi1' just with 'no shutdown' but on sdn1.1001 and sdn7.1001 both with 'bridge-group 1' and 'bridge-filter ipv6in acl_permit_all' and 'bridge-filter ipv6out acl_permit_all' I can only see the mac addr of sdn7.1001 but not for sdn1.1001 or bvi1. So the problem here is that the counters for 'show access-list acl_permit_all' and 'show bridge 1' are not increasing when I'm pinging between the routers.
2. But, if I add into 'interface bvi1' the following (I know that you tell me to don't do it jaja): 'vrf forwarding', 'ipv6 address 1234:2::1 ffff:ffff::', 'ipv6 access-group-in acl_permit_all', 'ipv6 enable' now I'm able to see all the mac address interfaces for sdn7.1001, sdn1.1001 and bvi1 and NOW the counters for 'show access-list acl_permit_all' and 'show bridge 1' are being increased when I'm pinging.
Anyway, I don't have a ping in both situations but I was wondering if I need to add something in the first case because not all the mac addresses on the interfaces are learned as in the 2nd case for example.
Regards,
Carmen Misa
On 21/02/2022 08:59 mc36 <> wrote:
https://letsmeet.hu/carmen
On 2/21/22 08:58, Maria Del Carmen Misa Moreira wrote:
Hi Csaba,
I'm free from now until 16h for the VC, just send a me link when you're
available.
On 19/02/2022 09:53 mc36 <> wrote:
okk, so i did the code duplication with this commit:
https://github.com/mc36/freeRouter/commit/e832c62068a5f3dce0dc11e75ebd4c1150d05625
so from now, you'll be able to count the acl hits on the bridged interfaces
too...
if you're brave enough and would get involved, you can write the counter
reports
yourself, you can use the flowspec for a sample... otherwise frederic will do
it...
regards,
cs
On 2/18/22 19:24, mc36 wrote:
yesss... so this second example was sent to show you a bad example too....
to have pure layer2 bridging (and not a fake layer2 over the arp entries)
please use the two examples with the bridge acls:
http://sources.nop.hu/cfg/p4lang-acl11.tst
http://sources.nop.hu/cfg/p4lang-acl12.tst
these dont have addressing on the bvi resulting in layer2 propagated to the
dataplane...
regards,
cs
On 2/18/22 19:07, Maria Del Carmen Misa Moreira wrote:
Well in this examples under bvi1 there is a vrf and IPv4/6, there are fake
like in loopback11 and loopback22 in the previous test
int bvi1
vrf for v1
ipv4 addr 1.1.2.1 255.255.255.0
ipv6 addr 1234:2::1 ffff:ffff::
ipv6 ena
exit
On 18/02/2022 18:37 mc36 <> wrote:
please dont... if you configure a vrf and ip to the bvi
then it'll see that you're trying to do layer3 over local bridge ports
and will result at dataplane in routing entries and not layer2...
this one is an example of this specific behavior:
http://sources.nop.hu/cfg/p4lang-rout019.tst
regards,
cs
On 2/18/22 18:31, Maria Del Carmen Misa Moreira wrote:
Well vrf is need at least for the 'interface bvi1' that belongs to 'brigde
1', if I understand correctly
On 18/02/2022 18:18 mc36 <> wrote:
so to use the bridge, better nuke the vrf, isis, basically everything
completely...
On 2/18/22 18:16, Maria Del Carmen Misa Moreira wrote:
Hi Csaba,
Quick question: if I set on one interface the 'bridge-group' it make sense to have on the same interface ISIS or LLDP? I'm reading that both are Layer 2 protocols but ISIS
will advertise the network that is reachable via that interface but if that
interface is going to act as bridge maybe this is illogical.
On 18/02/2022 17:07 mc36 <> wrote:
hi,
okk for the monday...
regards,
cs
On 2/18/22 17:06, Maria Del Carmen Misa Moreira wrote:
Hi Csaba,
Okey thanks. I'm going to take a look to bridges and your examples.
We can talk on Monday morning, I'm free all the morning.
Mmm I see the point, we need to use DPDK but since P4 switch is connected to
other 2 Juniper routers we cannot use it... I think.
On 18/02/2022 16:57 mc36 <> wrote:
hi,
any time could work to disucc online...
to be layer2 transparent, we can do bridging, and we support acls on bridge
ports...
here are the tests covering these:
http://sources.nop.hu/cfg/p4lang-acl11.tst
http://sources.nop.hu/cfg/p4lang-acl12.tst
the bad news is that currently the tofino cannot report hit counters for
these without code replication...
we have an open ticket for that at intel connected academy, and they're
working on it...
the good news is that the dpdk code already reports the hit counters on
these...
regards,
cs
On 2/18/22 16:05, Maria Del Carmen Misa Moreira wrote:
Hi Csaba,
If you have 15 minutes I would like to explain to you the new test that I
need to prepare for the next LHCONE meeting [next 29th of March]. Basically,
the idea is to
emulate the
connection between Tier1's and the P4 switch will need to be transparent at Layer 3 but I think that this is probably not possible using this policy-based routing... We need
something like 'Policy-based Switching' just using mac address and not IPs as
the next-hops. One time you told me about bridges on freertr and maybe this
could be a
solution, let
me your thoughts :) you are the super expert here and my support
Cheers,
Carmen Misa
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#195): https://groups.io/g/freertr/message/195
Mute This Topic: https://groups.io/mt/89296704/6006518
Group Owner:
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-
- Re: [RARE-users] [freertr] Test 3: Layer 2 - Abstract from Layer 3, mc36, 02/21/2022
- Re: [RARE-users] [freertr] Test 3: Layer 2 - Abstract from Layer 3, mc36, 02/23/2022
Archive powered by MHonArc 2.6.19.