RARE user and assistance email list

[Maria Del Carmen Misa Moreira <>]

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