Hi nagp,
The RPF-ID should be assigned to an LSP’s path, and to the mroute, at the tail
route not at the head.
IP multicast forwarding requires RPF checks to prevent loops, so at the tail we
need to RPF - this is done against the interface on which the packet arrives.
But in this case the only
Hi Neale,
In my case, this is what is happening - IP MC packets are arriving on a
normal interface, going from ip_input_inline to mfib_forward_lookup to
mfib_forward_rpf and there it is getting dropped because of rpf_id mismatch.
the mpls disposition node is not even figuring the path - what coul
Hi nagp,
If the packets arrive IP on an IP interface, then this is not the use-case for
RPF-ID.
Show me the mfib route and tell me the ingress interface.
/neale
From: Nagaprabhanjan Bellari
Date: Sunday, 9 July 2017 at 11:13
To: "Neale Ranns (nranns)"
Cc: vpp-dev
Subject: Re: [vpp-dev] A fe
> On 9 Jul 2017, at 07:31, Ehsan Shahrokhi wrote:
>
> Hi,
>
> I have two questions about stateful.
> First, why stateful implementation of NAT and ACL are independent? Was there
> any logic behind this? As it is expected that both ACL and NAT plugins use
> the same connection tracking code b
Hi Neale,
Please find the output of "show ip mfib table 1" below:
--
DBGvpp# show ip mfib table 1
ipv4-VRF:1, fib_index 1
(*, 0.0.0.0/0): flags:D,
Interfaces:
RPF-ID:0
multicast-ip4-chain
[@0]: dpo-drop ip4
(1.2.3.4, 229.1.1.2/32): flags:AA,
Interfaces:
mpls-tunnel1: Forward,
RPF
Hi nagp,
This is the head end. So there should not be an RPF-ID associated with the mfib
entry. Instead, there should be an accepting path for your phy interface, i.e;
ip mroute table 1 add 1.2.3.4 229.1.1.2 via FortyGigabitEthernet-6/0/1.1
Accept
regards,
neale
From: Nagaprabhanjan Bella
Ok, so:
An mroute should be associated with both an RPF-id as well as an accept
interface. For the head end ingress IP multicast traffic, the accept
interface is used as a check and for the tail end mpls terminating traffic
- the rpf_id associated with the mroute should match the rpf_id associated
Thanks Ole.
Could you please be more specific on the "state space"?
According to my understanding, the SNAT will remember the port mapping when
a new connection from inside to outside starts. Is this the state that you
mean? If so, does that mean the states are split by the RSS?
On Sat, Jul 8, 2
