R4# sh bgp ipv4 multicast 126.96.36.199
BGP routing table entry for 188.8.131.52/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
184.108.40.206 (inaccessible) from 220.127.116.11 (18.104.22.168)
Origin incomplete, metric 2, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
R4# sh ip route 22.214.171.124
Routing entry for 126.96.36.199/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blcoks:
* directly connected, via GigabitEthernet1.146
Route metric is 0, traffic share count is 1
bermovick wrote: »
I completely understand the point - although as I'm writing this, I'm not even sure of that. My thought was the need was to keep 'others' unicast routes out of your unicast RIB - hence having the parallel multicast RIB you're populating. The issue comes back down to BGP not advertising routes unless they're in the unicast RIB. So in order for a border router (with an eBGP peer) to forward the MBGP NLRI internally, they have to be put into the unicast table anyway!!!! I would assume either by redistributing the NLRI into their IGP or by running both unicast and multicast iBGP address-families internally. So what's the need for the multicast SAFI when the unicast SAFI is already required to do the exact same work?
The only sense I can make of this would be to have different BGP configurations (RRs, TE, etc), but that's seems like SO MUCH OVERHEAD.
So what's the need for the multicast SAFI when the unicast SAFI is already required to do the exact same work?
Once connected to R2, only allow this user to connect to R1.
Log any attempt to connect from R2 to any destination on port 80.
Configure R3 to drop any packets destined to the router with IP source route option (either loose or strict).