RARE user and assistance email list

[Maria Del Carmen Misa Moreira <>]

Hi Csaba,

Thanks!
I enable ECMP and add-path TX/RX in all the BGP processes but I continue with 
only one route in the table.
Now I have another question:
The ping and traceback are fine without the flow label:
     R11#traceroute fd01:40::44 vrf VRF_EXT source loopback100
     1 fd01:20:11::1 time=2
     2 fd01:20:14::4 time=1
     3 fd01:40::44 time=2

But when I add the flow label it never reaches the destination but the 2nd 
hope it’s exactly the same as in the previous trace path and the 3rd hope 
it’s the IP of the interface of the same router, I mean fd01:20:14::4 and 
fd01:20:44::4 belong to R4, the 1st one is connected to R1 and the 2nd one to 
R44 which is my destination:
      R11#traceroute fd01:40::44 vrf VRF_EXT source loopback100 flow 65540
      1 fd01:20:11::1 time=0
      2 fd01:20:14::4 time=1
      3 fd01:20:44::4 time=2
     4 null time=1000

I would expect the same behaviour in both cases simply because the 1st and 
2nd hopes are the same so how is this possible?
Regards,
Carmen Misa


> On 9 Jan 2023, at 16:13, mc36 <> wrote:
> 
> wait a bit... for policy routing, you even not need a routing protocol to 
> forward packets...
> if it matches the acl, it overrides normal forwarding decision and sends 
> out the packet...
> to have an other prefix, you need to enable ecmp to your bgp process.. it's 
> a local decision,
> and the prefixes must not be better or worse, exactly equal, in terms of 
> bgp best path...
> to overcome this, you could enable addpath to all the bgp sessions...
> br,
> cs
> 
> 
> On 1/9/23 16:09, Maria Del Carmen Misa Moreira wrote:
>> Hello again Csaba!
>> At this moment the issue comes in BGP because it only learns the prefix on 
>> one interface:
>>          B      fd01:40::44/128       20/0      ethernet1.30   
>> fd01:30:11::1   00:28:31
>> Here it should be the same for ethernet1.20, this is a case of bgp 
>> multiparth multi-as because each interface belong to a different AS 
>> (ethernet1.30 to AS30 and ethernet1.20 to AS20) so with the PBR I   m 
>> forcing to use AS20 when it match the flow label but it doesn   t know  
>> the route.
>> Cheers,
>> Carmen Misa
>>> On 9 Jan 2023, at 15:02, mc36 < <>> wrote:
>>> 
>>> hi,
>>> when it comes to software routing, it supports everything all the time, 
>>> even no command to select a profile! :)
>>> br,
>>> cs
>>> 
>>> On 1/9/23 14:54, Maria Del Carmen Misa Moreira wrote:
>>>> Hi Csaba,
>>>> Thanks!
>>>> Just to be sure, the version that I     m using allows to do PBR based 
>>>> on the flow label by using an access-list?
>>>> I     m just asking because on the switch we needed to change the 
>>>> profile.
>>>> Cheers,
>>>> Carmen Misa
>>>>> On 9 Jan 2023, at 13:46, mc36 < <>> wrote:
>>>>> 
>>>>> here is the mpls test case we discussed briefly: 
>>>>> http://sources.freertr.org/cfg/rout-bgp036.tst 
>>>>> <http://sources.freertr.org/cfg/rout-bgp036.tst>
>>>>> you can start it this way on your local computer:
>>>>> 
>>>>> wget freertr.org/rtr.zip <http://freertr.org/rtr.zip>
>>>>> unzip rtr.zip
>>>>> cd src
>>>>> ./c.sh
>>>>> ./tw.sh rout-bgp036.tst
>>>>> telnet localhost 20001
>>>>> telnet localhost 20002
>>>>> telnet localhost 20003
>>>>> 
>>>>> r1 is a pe with customer vrfs v2,v3,v4
>>>>> r2 is a p without customer vrfs
>>>>> r3 is a pe with customer vrfs v2,v3,v4
>>>>> v1 is the core vrf everywhere... i used static routing in this core vrf 
>>>>> but you can reuse your ospf to distribute the loopbacks...
>>>>> bgp on the pe routers should have vpnuni for ipv4 customer routes and 
>>>>> ovpnuni for ipv6 customer routes
>>>>> then you can redistribute whatever you want into the afi-vrf v2..v4.. 
>>>>> even an whole other routing protocol,
>>>>> like an ebgp process toward the customer router... one more note, 
>>>>> you'll need mutual redistribution between
>>>>> the ibgp and the ebgp processes to have connectivity...
>>>>> 
>>>>> doing this way you can eliminate the subinterfaces in the core and the 
>>>>> burden of running paralell routing protocols to have more vrfs....
>>>>> morever it's more secure because the core routes are fully separated 
>>>>> from the customer routes... just check it out! :)
>>>>> 
>>>>> br,
>>>>> cs
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 1/9/23 13:36, mc36 wrote:
>>>>>> On 1/9/23 13:16, Maria Del Carmen Misa Moreira wrote:
>>>>>>> https://letsmeet.hu/multione <https://letsmeet.hu/multione> 
>>>>>>> <https://letsmeet.hu/multione <https://letsmeet.hu/multione>>
>>>>>>> I     m here
>>>>>>> 
>>>>>>> 
>>>>>>>> On 9 Jan 2023, at 13:10, mc36 < <> 
>>>>>>>> < <>>> wrote:
>>>>>>>> 
>>>>>>>> okk then please drop me the zoom link and the topology.... im also 
>>>>>>>> free from now.. :)
>>>>>>>> 
>>>>>>>> On 1/9/23 11:50, Maria Del Carmen Misa Moreira wrote:
>>>>>>>>> Hi Csaba,
>>>>>>>>> Here it is. I         m completely free today or the rest of the 
>>>>>>>>> week, just let me know.
>>>>>>>>>> On 9 Jan 2023, at 11:02, mc36 < <> 
>>>>>>>>>> < <>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> hi,
>>>>>>>>>> please drop me the zip, it would be much easier for me to 
>>>>>>>>>> troubleshoot you on my local computer... :)
>>>>>>>>>> if you would like to join the session then lets have the zoom when 
>>>>>>>>>> you feel it fits to your time...
>>>>>>>>>> thanks,
>>>>>>>>>> cs
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 1/9/23 10:59, Maria Del Carmen Misa Moreira wrote:
>>>>>>>>>>> Hi Csaba,
>>>>>>>>>>> Right now I have a weird behaviour, I will try to explain it here 
>>>>>>>>>>>         1st problem: ping from R11 -> R3 works (R11 -> R1 -> R2 
>>>>>>>>>>> -> R3) but the other way around not (R3 -> R2 -> R1 (stops here 
>>>>>>>>>>> and not reaches R11). This is not very clear to my why because at 
>>>>>>>>>>> IP level it should work in both directions.
>>>>>>>>>>> 2nd problem: traceroute from R11 (AS 100) -> R33 (AS 300) is 
>>>>>>>>>>> fine: AS path 30 300 because it follows this path: R11 (AS 100) 
>>>>>>>>>>> -> R1 (AS 30) -> R2 (AS 30) -> R3(AS 30) -> R33 (AS 300) but the 
>>>>>>>>>>> ping doesn         t work (it reaches R3 but not R33).
>>>>>>>>>>> In general, the ping and the traceroute are fine until it reaches 
>>>>>>>>>>> the last router of the client (RX).
>>>>>>>>>>> I can send you an updated version of the simulation or directly 
>>>>>>>>>>> explain it to you in zoom.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Carmen Misa
>>>>>>>>>>>> On 5 Jan 2023, at 10:19, mc36 < <> 
>>>>>>>>>>>> < <>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> hi,
>>>>>>>>>>>> good to hear, thanks for the confirmation!
>>>>>>>>>>>> (and congrats again for your nice topology!:)
>>>>>>>>>>>> br,
>>>>>>>>>>>> cs
>>>>>>>>>>>> 
>>>>>>>>>>>> On 1/5/23 10:17, Maria Del Carmen Misa Moreira wrote:
>>>>>>>>>>>>> Hi Csaba,
>>>>>>>>>>>>> Thanks! Now it         s working perfectly, I missed that error
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Carmen Misa
>>>>>>>>>>>>>> El 4 ene 2023, a las 21:59, mc36 < <> 
>>>>>>>>>>>>>> < <>>> escribi     :
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> hi,
>>>>>>>>>>>>>> you're unbelivebeable! you built up a whole topology alone, 
>>>>>>>>>>>>>> without asking a question! congrats!
>>>>>>>>>>>>>> here is my findings after checking out the r4-r44 
>>>>>>>>>>>>>> connection... i enabled cdp on the interface:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R44#show cdp neighbor
>>>>>>>>>>>>>> interface     hostname     iface                     ipv4     
>>>>>>>>>>>>>> ipv6
>>>>>>>>>>>>>> ethernet1     R4                             ethernet3     
>>>>>>>>>>>>>> null     null
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R44#
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R4#show cdp neighbor
>>>>>>>>>>>>>> interface     hostname     iface     ipv4     ipv6
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R4#
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> but it indicates a one-way connection....
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R4#show interfaces ethernet3
>>>>>>>>>>>>>> ethernet3 is up
>>>>>>>>>>>>>> description:
>>>>>>>>>>>>>> state changed 3 times, last at 2023-01-04 20:42:07, 00:10:46 
>>>>>>>>>>>>>> ago
>>>>>>>>>>>>>> last packet input never ago, output 00:00:00 ago, drop never 
>>>>>>>>>>>>>> ago
>>>>>>>>>>>>>> type is ethernet, hwaddr=0000.4444.0005, mtu=1500, bw=100mbps
>>>>>>>>>>>>>> received 0 packets (0 bytes) dropped 0 packets (0 bytes)
>>>>>>>>>>>>>> transmitted 1817 packets (103734 bytes) macsec=false sgt=false
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R4#
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> on r4 i cannot see received packets... on r44 i have both rx 
>>>>>>>>>>>>>> and tx:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R44#show interfaces ethernet1
>>>>>>>>>>>>>> ethernet1 is up
>>>>>>>>>>>>>> description:
>>>>>>>>>>>>>> state changed 3 times, last at 2023-01-04 20:42:07, 00:12:10 
>>>>>>>>>>>>>> ago
>>>>>>>>>>>>>> last packet input 00:00:00 ago, output 00:00:00 ago, drop 
>>>>>>>>>>>>>> 00:00:00 ago
>>>>>>>>>>>>>> type is ethernet, hwaddr=0000.8888.0001, mtu=1500, bw=100mbps
>>>>>>>>>>>>>> received 6069 packets (363198 bytes) dropped 1982 packets 
>>>>>>>>>>>>>> (112310 bytes)
>>>>>>>>>>>>>> transmitted 4088 packets (246816 bytes) macsec=false sgt=false
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> R44#
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> then grepping around for 46025 showed me that you reused this 
>>>>>>>>>>>>>> port for both r4-r44 and r3-r33 connection!
>>>>>>>>>>>>>> so you had a competition, one or the other was able to use the 
>>>>>>>>>>>>>> interface and communicate... :)
>>>>>>>>>>>>>> br,
>>>>>>>>>>>>>> cs
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 1/4/23 21:26, Maria Del Carmen Misa Moreira wrote:
>>>>>>>>>>>>>>> Hi Csaba,
>>>>>>>>>>>>>>> I attach here all the hw and sw files that I         m using 
>>>>>>>>>>>>>>> for the simulation with topology.png and readme.txt files for 
>>>>>>>>>>>>>>> clarification and start_topology.sh to load and start all the 
>>>>>>>>>>>>>>> routers.
>>>>>>>>>>>>>>> All the boxes are using Freertr and the log at the beginning 
>>>>>>>>>>>>>>> is fine without errors:
>>>>>>>>>>>>>>> info cfgInit.doInit:cfgInit.java:775 booting
>>>>>>>>>>>>>>> info cfgInit.doInit:cfgInit.java:957 initializing hardware
>>>>>>>>>>>>>>> info cfgInit.doInit:cfgInit.java:963 applying defaults
>>>>>>>>>>>>>>> info cfgInit.doInit:cfgInit.java:984 applying configuration
>>>>>>>>>>>>>>> info cfgInit.doInit:cfgInit.java:1019 boot completed
>>>>>>>>>>>>>>> Tomorrow I will be able from 8h until 17h or later if it      
>>>>>>>>>>>>>>>    s needed.
>>>>>>>>>>>>>>> Cheeers,
>>>>>>>>>>>>>>> Carmen Misa
>>>>>>>>>>>>>>>> El 4 ene 2023, a las 13:24, mc36 < <> 
>>>>>>>>>>>>>>>> < <>>> escribi     :
>>>>>>>>>>>>>>>> hi,
>>>>>>>>>>>>>>>> so bgp peer establishment is somewhat random: the original 
>>>>>>>>>>>>>>>> rfc does not mention that the higher/lower ip should 
>>>>>>>>>>>>>>>> initiate the tcp
>>>>>>>>>>>>>>>> so i'm copying the ios xr behavior: it tries active then 
>>>>>>>>>>>>>>>> passive open with random timers and fingers crossed, it'll 
>>>>>>>>>>>>>>>> come up...
>>>>>>>>>>>>>>>> all my interop with cisco xr, cisco xe, junos, frr and self 
>>>>>>>>>>>>>>>> tests (about 800 bgp tests in total) pass fine without a 
>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>> retry so it cannot be that bad.. the only issue i know about 
>>>>>>>>>>>>>>>> is with bird in my dn42 peerings, which does wildcard listen 
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> port 179, causing every active open to succeed, but 
>>>>>>>>>>>>>>>> sometimes it's simultaneous with their active open resulting 
>>>>>>>>>>>>>>>> in collisions
>>>>>>>>>>>>>>>> at the bird side.. then their side closes one or the other 
>>>>>>>>>>>>>>>> without a notify message causing log flood on freerouter side
>>>>>>>>>>>>>>>> until the session finally comes up...
>>>>>>>>>>>>>>>> in your topology, i've a lot of questions:
>>>>>>>>>>>>>>>> -what is that (as10, as20, as30) notation? the common way is 
>>>>>>>>>>>>>>>> that one box belongs to one asn?
>>>>>>>>>>>>>>>> -what box is freerouter and what the other boxes are?
>>>>>>>>>>>>>>>> -do you see anything in the freerouter and the opposite 
>>>>>>>>>>>>>>>> box's logs?
>>>>>>>>>>>>>>>> -can you share the simulation in order to be able to 
>>>>>>>>>>>>>>>> reproduce?
>>>>>>>>>>>>>>>> -if not, can we have a debug session together?
>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>> cs
>>>>>>>>>>>>>>>> On 1/4/23 12:24, Maria Del Carmen Misa Moreira wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>> I have a full mesh topology RX configured with iBGP, OSPF, 
>>>>>>>>>>>>>>>>> 3 VLANs and 3 VRFs (BGP is configured with the address of 
>>>>>>>>>>>>>>>>> the loopbacks: 1 loopback per VLAN). Every router has a 
>>>>>>>>>>>>>>>>> client RXX with OSPF passive, eBGP, a different AS number 
>>>>>>>>>>>>>>>>> and 1 VRF.
>>>>>>>>>>>>>>>>> (AS100)                 R11 ---- (AS10, AS20, AS30) R1 ---- 
>>>>>>>>>>>>>>>>> (AS10, AS20, AS30)R4 ---- (AS400) R44
>>>>>>>>>>>>>>>>> *|*|**
>>>>>>>>>>>>>>>>> (AS200) R22 ---- (AS10, AS20, AS30) R2 ---- (AS10, AS20, 
>>>>>>>>>>>>>>>>> AS30) R3 ----(AS300) R33
>>>>>>>>>>>>>>>>> The topology is working fine so I can ping each other, iBGP 
>>>>>>>>>>>>>>>>> is up but eBGP is not completly up. I noted that R11 and 
>>>>>>>>>>>>>>>>> R22 are always up but for R33 and R44 it depends... This is 
>>>>>>>>>>>>>>>>> the behaviour that I'm seeing: I run the simulation and 
>>>>>>>>>>>>>>>>> R11/R22 bring up and     also R33 (not R44), then, I run 
>>>>>>>>>>>>>>>>> again the simulation with exactly the same configuration 
>>>>>>>>>>>>>>>>> and sometimes it happens that R44 brings up and not R33 or 
>>>>>>>>>>>>>>>>> even worst none of them (R33,
>>>>>>>>>>>>>>> R44).
>>>>>>>>>>>>>>>>> Any idea? I have no idea why only one of those (R33, R44) 
>>>>>>>>>>>>>>>>> brings up and not the other and when you run it again it be 
>>>>>>>>>>>>>>>>> opposite behaviour.
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Camen Misa
>>>>>>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature