Hey guys
I might have some news for this feed.
Last weekend I was double upgradeing one RV325. (md5 issue, Open VPN client 2.4.5+ bitching/not working)
Former software generated certificates signed only with md5.
I had to open up the TAC case, get the beta, RV32X_v1.4.2.19ts-13_20181226-code.bin
now the nice part was, I didnt need to delete whole config of the router.
I only needed to generate all the certificates regarding open vpn...carefull..also the server certificate is signed
by md5, (although the self signed certificate of the router is signed with sha, dont understand whole situation...)
After regenerating all the certificates and all the open VPN accounts, upgraded my open vpn client to 2.4.6,
everything works.
Generated couple users for future :-) cause official release still does not support generation of certificates signed by anything else than md5.
and finally I upgraded to official release RV32X_v1.4.2.20_20181224-code.bin.
Works like charm...until next trouble :-)
HTH
Leo
... View more

Search the forum.
I had a same problem.
I found somewhere a US number, which I called and I was able to open up the TAC case and eventually
get the beta firmware, that fixed what I needed.
SMB segment is heavily neglected by Cisco.
last weekend I was double upgradeing RV325 from sw from 2017 to a beta that was able to generate proper certificates for open vpn clients (so the newest open vpn client doesnt bitch and works). I generated couple users "for future" and then I upgraded to official release which allegedly patched some severe CVEs.
:-)
I will try to find you the number.
Leo
... View more

Hello Madame
Are we able to get at least some info, when we could be awaiting the new sw with this thing fixed please?
When I downloaded the beta version in early summer TAC said it would be in the fall 2018.
Now we are in 2019 and still nothing.
I have it deployed in one of my clients small office and I need to have it fixed.
Thank you in advance.
... View more

Hello gents
The setup is RTR-A ***** RTR-B********RTR-C
router B is the RP
I am running PIM BIDIR on this network.
RTR-A is Cisco 4300, RTR-C is Cisco 2911.
I want clients on LAN segments of RTR-A and RTR-C be able to mutually communicate
to a group 232.112.112.112.
Clients are not able to send igmp reports, hence I am using ip igmp static-group 232.112.112.112
(ip igmp joinn-group is not working either)
On RTR-C I correctly see the output
(*,232.112.112.112), 1d02h/-, RP 172.23.223.129, flags: BC
Bidir-Upstream: GigabitEthernet0/0.28581150, RPF nbr: 172.23.223.65
Incoming interface list:
GigabitEthernet0/0/0.80, Accepting/Sparse
GigabitEthernet0/0.28581150, Accepting/Sparse
Outgoing interface list:
GigabitEthernet0/0/0.80, Forward/Sparse, 00:25:22/00:01:37
Gi0/0.28581150, Bidir-Upstream/Sparse, 01:02:22/stopped
and as you can see, there is C flag, indicating, that I have configured ip igmp static-group 232.112.112.112
on interface Gig0/0/0.80 hence the stream will flow down to LAN.
and I can see
RTR-C#sh ip pim vrf voice interface gigabitEthernet 0/0/0.80 df
* implies this system is the DF
Interface RP DF Winner Metric Uptime
GigabitEthernet0/0/0.80 172.23.223.129 *10.186.223.2 0 1d02h
On RTR-A on other hand I can not see the latter
RTR-A#sh ip pim vrf voice interface gigabitEthernet 0/0/2.80 df
* implies this system is the DF
Interface RP DF Winner Metric Uptime
and I can not see the LAN segment to be in incomming nor outgoing interface lists for the group
RTR-A#sh ip mroute vrf voice 232.112.112.112
(*,232.112.112.112), 1d02h/-, RP 172.23.223.129, flags: B
Bidir-Upstream: GigabitEthernet0/0/0.36151150, RPF nbr: 172.23.223.129
Incoming interface list:
GigabitEthernet0/0/0.36151150, Accepting/Sparse
even if I have ip igmp static-group 232.112.112.112 configured on Gig0/0/0.80
RTR-A#sh ip igmp vrf voice membership 232.112.112.112 Channel/Group Reporter Uptime Exp. Flags Interface *,232.112.112.112 0.0.0.0 00:15:32 stop 2SA Gi0/0/2.80 RTR-A#
How to force the RTR-A to be the DF and get the correct output to my sh ip mroute table.
This is the initial state I had it in. And then I lost OIL completelty on RTR-A and there was no config change.
(*,232.112.112.112), 1d02h/-, RP 172.23.223.129, flags: B
Bidir-Upstream: GigabitEthernet0/0/0.36151150, RPF nbr: 172.23.223.129
Incoming interface list:
GigabitEthernet0/0/0.36151150, Accepting/Sparse
Outgoing interface list:
Gi0/0/0.36151150, Bidir-Upstream/Sparse, 00:00:07/stopped
funny stuff is, that the traffic is allegedly flowing both ways, but from the outputs it should not at all.
Any hints please?
Thank you very much
Leo
... View more

This is MPLS VPNv4 route, the reasons why you are not able to ping can be various.
traceroute in case of MPLS will not help much, but it can, if it is allowed in the network (it usually is not)
(do not recommend to play with it in production networks)
1.check whether the source IP of the ping is reachable for the opposite side
(on opposite side, check whether it can see in pertaining vrf the route to the source IP
the same way, as you are checking for the route on your end)
2.check whether your MPLS transport is functional!! this is crucial.
Check associated label stack to your route on your router
Check assossiations of labels for destination PE router loopback along the way
easy ...first check, whether you can ping destination PE loopback
then do traceroute for destination PE loopback
then check whether LDP is allowed all the way in traceroute
and then go one hop at a time and check labels in sh mpls forwarding-table
3. If PE-CE connections are involved, you need to check routing end-to-end in both
directions, both ends.
If you want to understand this, you need to dismantle the whole problem and go
one thing at a time.
... View more

Hi,Try using this ip vrf A rd 65432:20130 route-replicate from vrf B unicast connected route-map rm-b-2-a
obviously, this is for connected routes, in vrf B.
But there are other options, so try to play with it.
My exp is, that it wont get advertised to vpnv4.
let me know, if it worked pls.
... View more

Hi Peter,
could you please check the path to those shared docs? (i get error, when clicking on it)
I've got more questions regarding auto-rp and can't reach them.
I believe the info I am searching for is right there.
for speed check:
Are 224.0.1.39/40 subject to RPF? (just confirming)
If I receive disco msg about the same group from 2 routers, which one will be used (info-source)?
(whats the process? curretly info source is flapping between 2 routers, how to make one of them primary?)
Thank you
Regards
LG
... View more

that happens, no problem.
Just for confirmation
if I use
ip verify source unicast reachable-via rx
on intf where my DG is pointing to (intf X) WITHOUT allow-default, the router would need to have the fib entry for each and every source IP that comes in and that entry would need to be pointing to intf X.
(which is not feasible, unless the router learns the whole inet table)
If I use allow-default option, the router is happy to use my DG for RPF checks of source IPs and lets
everything in except the sources you mentioned.
Do I understand it correctly, that rx allow-default means that the DG must be pointing to the interface I am receiving the packets on?
If I had the DG pointing to intf A and I configured xxxx ANY allow-default on intf B , would that work?
Thanks for your time!
LG
... View more

Hi Peter
I would like to ask one more additional question to this topic please.
Does
ip verify unicast source reachable-via rx
have any impact if used with allow-default option? (presuming that DG is pointing to the interface)
Cause from my pov it will allow everything that comes in from
the interface to which the DG is pointing.
So removing the command ip verify source unicast reachable-via rx allow-default
will basically do the same as having it there => allow all the traffic.
Can you please help understand?
Thank you
LG
... View more

Hi Paul,
Thank you for the solution.
How about the old syntax, on newer codes it already doesn't work?
Should I count on complete transition to nvi with my NATs whatsoever?
Thanks for opinion.
regards
Leo
... View more