To stop the keyboard from popping up on a Samsung device, go to Settings > General management > Physical keyboard and toggle off “Show on-screen keyboard”
Author: Anas
OSPF
OSPF
OSPF is a link state routing protocol, an IGP
OSPF exchanges routing information with other routers , neighbors over LSA
LSA contains information on the link state (Subnet(s) on interface(s)) and link metric (cost to reach that IP and mask)
OSPF advertises this information to neighboring routers exactly as the original advertising router advertised it, in fact the whole area gets same LSAs and it is up to individual routers to compute SPT (Shortest Path Tree [to every subnet])
Received LSAs are stored in a local database called the link-state database (LSDB).
and then local router spreads LSAs through the OSPF area, interface by interface – link local multicast to next interface’s link local multicast.
All OSPF routers run Dijkstra’s shortest path first (SPF) algorithm to construct a loop-free topology of shortest paths. OSPF dynamically detects topology changes within the network and calculates loop-free paths in a short amount of time – this is the main purpose of all the routing protocols so we dont have to add static routes through the network and OSPF brings that
Each router sees itself as the root or top of the SPF tree (SPT), and the SPT contains all network destinations within the OSPF domain. The SPT differs for each OSPF router, but the LSDB used to calculate the SPT is identical for all OSPF routers.
There seems to be some difference in connectivity to the 10.3.3.0/24 network from R1’s and R4’s SPTs. From R1’s perspective, the serial link between R3 and R4 is missing; from R4’s perspective, the Ethernet link between R1 and R3 is missing.
The SPTs give the illusion that no redundancy exists to the networks, but remember that an SPT shows the shortest path to reach a network and is built from the LSDB, which contains all the links for an area.
A router can run multiple OSPF processes. Each process maintains its own unique database, and routes learned in one OSPF process are not available to a different OSPF process without redistribution of routes between processes.
The OSPF process numbers are locally significant and do not have to match among routers. If OSPF process number 1 is running on one router and OSPF process number 1234 is running on another, the two routers can become neighbors.
Areas
OSPF allows scalability by using areas
Area is set at interface level
An interface can belong to only one area
All routers within the same OSPF area maintain an identical copy of the LSDB.
Inside an area:
-A full SPT calculation runs when a link flaps within the area
-With a single area, the LSDB increases in size and becomes unmanageable, as area grows, consumes more memory, and takes longer during the SPF computation process.
-With a single area, no summarization of route information occurs.
If a router has interfaces in multiple areas, the router has multiple LSDBs (one for each area)
The internal topology of one area is invisible from outside that area. Outside areas only learn the prefixes of that area, only topology is not visible (like which prefix is attached to which router), outside areas just know about the prefixes
If a topology change occurs (such as a link flap or an additional network added) within an area, all routers in the same OSPF area calculate the SPT again. Routers outside that area do perform a partial SPF calculation
Segmenting the OSPF domain into multiple areas reduces the size of the LSDB for each area, making SPT calculations faster and decreasing LSDB flooding between routers when a link flaps.
Just because a router connects to multiple OSPF areas does not mean the routes from one area will be injected into another area
Area 0 is a special area called backbone area. OSPF uses a two-tier hierarchy in which all areas must connect to the upper tier Area 0.
All areas inject routing information into Area 0
Area 0 advertises the routes into other areas
Area ID is a 32-bit field and can be formatted as decimal (0 through 4294967295) or dotted decimal (0.0.0.0 through 255.255.255.255) like IPv4
If we use decimal format on one router and dotted-decimal format on a different router, the routers will be able to form an adjacency.
ABRs
Area border routers (ABRs) are OSPF routers connected to Area 0 and another OSPF area, ABR is responsible for sending its connected Area’s routes into -> Area 0 and send all the learned routes from all areas from Area 0’s routes into its areas
Every ABR must participate in Area 0
ABRs compute an SPT for every area that they participate in
OSPF Communication
OSPF runs directly over IPv4, using protocol 89 and does not use TCP or UDP because OSPF communication never travels over distance, it stays on link local using multicast
There are two OSPF multicast addresses:
AllSPFRouters: IPv4 address 224.0.0.5, 01:00:5E:00:00:05.
AllDRouters: IPv4 address 224.0.0.6, 01:00:5E:00:00:06
Remember multicast address of OSPF using 5E, E if flipped becomes M and 5 is S so Multicast
OSPF Packet Types
| 1 | Hello | Packets are sent out periodically on all OSPF interfaces to discover new neighbors while also ensuring that existing neighbors are still online. |
| 2 | Database description (DBD or DDP) | Packets are exchanged when an OSPF adjacency is first being formed. These packets are used to describe the contents of the LSDB, Remember only describe |
| 3 | Link-state request (LSR) | When a router thinks that part of its LSDB is stale after reading the DBD, it may request a portion of a neighbor’s database by using this packet type. |
| 4 | Link-state update (LSU) | This is the “LSA” for a specific network link, and normally it is sent in direct response to an LSR. |
| 5 | Link-state acknowledgment | These packets are sent in response to the flooding of LSAs, thus making the flooding a reliable transport feature. |
Router ID
The OSPF router ID (RID) is unique and identifies router in OSPF domain as a unique participant. The OSPF RID is an essential component in building an OSPF topology. The output of some OSPF commands uses the term neighbor ID as a synonym for RID. The RID must be unique for each OSPF process in an OSPF domain and must be unique between OSPF processes on a router.
The RID is dynamically allocated by default, using the highest IP address of any up loopback interfaces. If there are no up loopback interfaces, the highest IP address of any active up physical interfaces becomes the RID when the OSPF process initializes. The OSPF process selects the RID when the OSPF process initializes, and it does not change until the process restarts. This means that the RID can change if a higher loopback address has been added and the process (or router) is restarted.
Setting a static RID helps with troubleshooting and reduces LSAs when an RID changes in an OSPF environment
OSPF Hello Packets
OSPF Hello packets discover and maintain already discovered neighbors
OSPF router sends out hello on AllSPFRouters 224.0.0.5
Information carried inside OSPF hello:
| Router ID (RID) | A unique 32-bit ID within an OSPF domain that is used to build the topology. |
| Authentication Options | A field that allows secure communication between OSPF routers to prevent malicious activity. Options are none, plaintext, or Message Digest 5 (MD5) authentication. |
| Area ID | The OSPF area that the OSPF interface belongs to. It is a 32-bit number that can be written in dotted-decimal format (0.0.1.0) or decimal (256). |
| Interface Address Mask | The network mask for the primary IP address for the interface out which the hello is sent. |
| Interface Priority | The router interface priority for DR elections. |
| Hello Interval | The time interval, in seconds, at which a router sends out hello packets on the interface. |
| Dead Interval | The time interval, in seconds, that a router waits to hear a hello from a neighbor router before it declares that router down. |
| Designated Router and Backup Designated Router | The IP address of the DR and backup DR (BDR) for that network link. |
| Active Neighbor | A list of OSPF neighbors seen on that network segment. To qualify in this neighbor list a router must have received a hello from the neighbor within the dead interval. |
See how Active neighbors and DR / BDR information is inside the hello packets
Neighbors
An OSPF neighbor is a router that shares a common OSPF-enabled network link
Discover neighbors through hello messages
An adjacent OSPF neighbor is an OSPF neighbor that has shared all the LSDB to its neighbor as opposed to 2 way
OSPF Neighbor States
| Down | Router has not yet received hello yet |
| Attempt | A state that is relevant to nonbroadcast multi-access (NBMA) networks that do not support broadcast and require neighbor configuration. This state indicates that the router is still attempting communication. |
| Init | A state in which a hello packet has been received from another router, but bidirectional communication has not been established. Remember from “in” in Init |
| 2-Way | A state in which bidirectional communication has been established. If a DR or BDR is needed, the election occurs during this state. |
| ExStart | The first state in forming an adjacency. Routers identify which router will be the primary or secondary for the LSDB synchronization. |
| Exchange | A state during which routers are exchanging link states by using DBD packets. |
| Loading | A state in which LSR packets are sent to the neighbor, asking for the more recent LSAs that have been discovered (but not received) in the Exchange state. |
| Full | A state in which neighboring routers are fully adjacent. |
Neighbor Adjacency Requirements
R – The RIDs must be unique for whole OSPF domain, To prevent errors, they should be unique for the entire OSPF routing domain.
S – The interfaces must share a common subnet. OSPF uses the interface’s primary IP address when sending out OSPF hellos. The network mask (netmask) in the hello packet is used to extract the network ID of the hello packet.
M – The interface maximum transmission unit (MTU) must match because the OSPF protocol does not support fragmentation.
A – The area ID must match for that segment.
D – The need for a DR must match for that segment.
H – OSPF hello and dead timers must match for that segment.
A – The authentication type and credentials (if any) must match for that segment.
T – Area type flags must be identical for that segment (stub, NSSA, and so on).
see step 2 and 3, init and 2 way, how the neighbor list builds up
R1# debug ip ospf adj
OSPF adjacency events debugging is on
*21:10:01.735: OSPF: Build router LSA for area 0, router ID 192.168.1.1,
seq 0x80000001, process 1
*21:10:09.203: OSPF: 2 Way Communication to 192.168.2.2 on GigabitEthernet0/0,
state 2WAY
*21:10:39.855: OSPF: Rcv DBD from 192.168.2.2 on GigabitEthernet0/0 seq 0x1823
opt 0x52 flag 0x7 len 32 mtu 1500 state 2WAY
*21:10:39.855: OSPF: Nbr state is 2WAY
*21:10:41.235: OSPF: end of Wait on interface GigabitEthernet0/0
*21:10:41.235: OSPF: DR/BDR election on GigabitEthernet0/0
*21:10:41.235: OSPF: Elect BDR 192.168.2.2
*21:10:41.235: OSPF: Elect DR 192.168.2.2
*21:10:41.235: DR: 192.168.2.2 (Id) BDR: 192.168.2.2 (Id)
*21:10:41.235: OSPF: GigabitEthernet0/0 Nbr 192.168.2.2: Prepare dbase exchange
*21:10:41.235: OSPF: Send DBD to 192.168.2.2 on GigabitEthernet0/0 seq 0xFA9
opt 0x52 flag 0x7 len 32
*21:10:44.735: OSPF: Rcv DBD from 192.168.2.2 on GigabitEthernet0/0 seq 0x1823
opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*21:10:44.735: OSPF: GigabitEthernet0/0 Nbr 2.2.2.2: Summary list built, size 1
*21:10:44.735: OSPF: Send DBD to 192.168.2.2 on GigabitEthernet0/0 seq 0x1823
opt 0x52 flag 0x2 len 52
*21:10:44.743: OSPF: Rcv DBD from 192.168.2.2 on GigabitEthernet0/0 seq 0x1824
opt 0x52 flag 0x1 len 52 mtu 1500 state EXCHANGE
*21:10:44.743: OSPF: Exchange Done with 192.168.2.2 on GigabitEthernet0/0
*21:10:44.743: OSPF: Send LS REQ to 192.168.2.2 length 12 LSA count 1
*21:10:44.743: OSPF: Send DBD to 192.168.2.2 on GigabitEthernet0/0 seq 0x1824
opt 0x52 flag 0x0 len 32
*21:10:44.747: OSPF: Rcv LS UPD from 192.168.2.2 on GigabitEthernet0/0 length
76 LSA count 1
*21:10:44.747: OSPF: Synchronized with 192.168.2.2 GigabitEthernet0/0, state FULL
*21:10:44.747: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.2 on GigabitEthernet0/0
from LOADING to FULL, Loading DoneOSPF Configuration
Most configuration for OSPF is done under OSPF process but some configuration can be done at interface level
command ip ospf process-id area area-id [secondaries none]. This method also adds secondary connected networks to the LSDB unless the secondaries none option is used.
Making the network interface passive still adds the network segment to the LSDB but prevents the interface from forming OSPF adjacencies. A passive interface does not send out OSPF hellos and does not process any received OSPF packets.
The command passive-interface interface-id under the OSPF process makes the interface passive, and the command passive-interface default makes all interfaces passive, Then command no passive-interface interface-id is used to make interfaces non passive
Different ways of configuring OSPF
R1
router ospf 1
router-id 192.168.1.1
network 0.0.0.0 255.255.255.255 area 1234R2
router ospf 1
router-id 192.168.2.2
network 10.123.1.2 0.0.0.0 area 1234
network 10.24.1.2 0.0.0.0 area 1234R3
router ospf 1
router-id 192.168.3.3
network 0.0.0.0 255.255.255.255 area 1234
passive-interface GigabitEthernet0/1R3
router ospf 1
router-id 192.168.3.3
network 0.0.0.0 255.255.255.255 area 1234
passive-interface GigabitEthernet0/1R4
router ospf 1
router-id 192.168.4.4
!
interface GigabitEthernet0/0
ip ospf 1 area 0
interface Serial1/0
ip ospf 1 area 1234R5
router ospf 1
router-id 192.168.5.5
network 10.45.1.0 0.0.0.255 area 0
network 0.0.0.0 255.255.255.255 area 56R6
router ospf 1
router-id 192.168.6.6
network 0.0.0.0 255.255.255.255 area 56R4# show ip ospf interface
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.45.1.4/24, Area 0, Attached via Interface Enable
Process ID 1, Router ID 192.168.4.4, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 192.168.5.5, Interface address 10.45.1.5
Backup Designated router (ID) 192.168.4.4, Interface address 10.45.1.4
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
..
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.5.5 (Designated Router)
Suppress hello for 0 neighbor(s)
Serial1/0 is up, line protocol is up
Internet Address 10.24.1.4/29, Area 1234, Attached via Interface Enable
Process ID 1, Router ID 192.168.4.4, Network Type POINT_TO_POINT, Cost: 64
Topology-MTID Cost Disabled Shutdown Topology Name
0 64 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
..
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.2.2
Suppress hello for 0 neighbor(s)R1# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/0 1 1234 10.123.1.1/24 1 DROTH 2/2R2# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se1/0 1 1234 10.24.1.1/29 64 P2P 1/1
Gi0/0 1 1234 10.123.1.2/24 1 BDR 2/2R3# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/1 1 1234 10.3.3.3/24 1 DR 0/0
Gi0/0 1 1234 10.123.1.3/24 1 DR 2/2R4# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/0 1 0 10.45.1.4/24 1 BDR 1/1
Se1/0 1 1234 10.24.1.4/29 64 P2P 1/1PID
The OSPF process ID associated with this interface
Nbrs F
This is neighbors that are “Fully” adjacent, The number of neighbor OSPF routers for a segment that are fully adjacent
Nbrs C
This is neighbor “Count”, The number of neighbor OSPF routers for a segment that have been detected and are in a 2-Way state
DROTHERs do not establish full adjacency with other DROTHERs.
show ip ospf neighbor [detail]
R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.4.4 0 FULL/ - 00:00:38 10.24.1.4 Serial1/0
192.168.1.1 1 FULL/DROTHER 00:00:37 10.123.1.1 GigabitEthernet0/0
192.168.3.3 1 FULL/DR 00:00:34 10.123.1.3 GigabitEthernet0/0Notice that the state for R2’s S1/0 interface does not reflect a DR status with its peering with R4 (192.168.4.4) because a DR can not exist on a point-to-point link so it simply shows –
R1# show ip route ospf
! Output omitted for brevity
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
Gateway of last resort is not set
O 10.3.3.0/24 [110/2] via 10.123.1.3, 00:18:54, GigabitEthernet0/0
O 10.24.1.0/29 [110/65] via 10.123.1.2, 00:18:44, GigabitEthernet0/0
O IA 10.45.1.0/24 [110/66] via 10.123.1.2, 00:11:54, GigabitEthernet0/0
O IA 10.56.1.0/24 [110/67] via 10.123.1.2, 00:11:54, GigabitEthernet0/0two sets of numbers are presented in brackets (for example, [110/2]). The first number is the administrative distance (AD), which is 110 by default for OSPF, and the second number is the metric
intra-area (O routes)
inter-area (O IA routes)
R5# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.3.3.0/24 [110/67] via 10.45.1.4, 00:04:13, GigabitEthernet0/0
O IA 10.24.1.0/29 [110/65] via 10.45.1.4, 00:04:13, GigabitEthernet0/0
O IA 10.123.1.0/24 [110/66] via 10.45.1.4, 00:04:13, GigabitEthernet0/0routing table for R5 and R6. R5 and R6 contain only inter-area routes in the OSPF routing table because intra-area routes are directly connected. Directly connected routes are not installed in routing table only because of AD competition only, these O Intra area routes will still show in OSPF LSDB
Routes that are injected into an OSPF domain through redistribution are known as external OSPF routes.
The router that redistributes prefixes into an OSPF domain, the router is called an autonomous system boundary router (ASBR)
There are 2 types of external routes:
Type 1 routes are preferred over Type 2 routes.
The Type 1 metric equals the redistribution metric plus the total path metric to the ASBR. In other words, as the LSA propagates away from the originating ASBR, the metric increases.
The Type 2 metric equals only the redistribution metric. The metric is the same for the router next to the ASBR as the router 30 hops away from the originating ASBR. This is the default external metric type used by OSPF.
172.16.6.0/24 network is redistributed as a Type 1 route, and the 172.31.6.0/24 network is redistributed as a Type 2 route
External OSPF network routes are marked as O E1 and O E2
R1# show ip route ospf
! Output omitted for brevity
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2
Gateway of last resort is not set
O 10.3.3.0/24 [110/2] via 10.123.1.3, 23:20:25, GigabitEthernet0/0
O 10.24.1.0/29 [110/65] via 10.123.1.2, 23:20:15, GigabitEthernet0/0
O IA 10.45.1.0/24 [110/66] via 10.123.1.2, 23:13:25, GigabitEthernet0/0
O IA 10.56.1.0/24 [110/67] via 10.123.1.2, 23:13:25, GigabitEthernet0/0
O E1 172.16.6.0 [110/87] via 10.123.1.2, 00:01:00, GigabitEthernet0/0
O E2 172.31.6.0 [110/20] via 10.123.1.2, 00:01:00, GigabitEthernet0/0R2# show ip route ospf | begin Gateway
Gateway of last resort is not set
O 10.3.3.0/24 [110/2] via 10.123.1.3, 23:24:05, GigabitEthernet0/0
O IA 10.45.1.0/24 [110/65] via 10.24.1.4, 23:17:11, Serial1/0
O IA 10.56.1.0/24 [110/66] via 10.24.1.4, 23:17:11, Serial1/0
O E1 172.16.6.0 [110/86] via 10.24.1.4, 00:04:45, Serial1/0
O E2 172.31.6.0 [110/20] via 10.24.1.4, 00:04:45, Serial1/0metric for the 172.31.6.0/24 network is the same on R1 as it is on R2, but the metric for the 172.16.6.0.0/24 network differs on two routers because Type 1 metrics include the path metric to the ASBR.
OSPF supports advertising the default route into the OSPF domain. The advertising router must have a default route in its routing table for the default route to be advertised. To advertise the default route, you use the command default-information originate [always] [metric metric-value] [metric-type type-value] underneath the OSPF process. The always optional keyword advertises the default route regardless of whether a default route exists in the RIB. In addition, the route metric can be changed with the metric metric-value option, and the metric type can be changed with the metric-type type-value option.
R1
ip route 0.0.0.0 0.0.0.0 100.64.1.2
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
default-information originateOSPF advertises the default route as an external OSPF route.
R2# show ip route | begin Gateway
Gateway of last resort is 10.12.1.1 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 10.12.1.1, 00:02:56, GigabitEthernet0/1
C 10.12.1.0/24 is directly connected, GigabitEthernet0/1
C 10.23.1.0/24 is directly connected, GigabitEthernet0/2Order of Route Preference
O — Intra-Area route
Most preferred
Best because it stays inside the same area
O IA — Inter-Area route
From another area
Preferred over all external types
N1 — NSSA External Type 1
External + internal cost
Same logic as E1 but inside NSSA
Most preferred external type
E1 — External Type 1
External + internal cost to ASBR
Preferred over type 2
N2 — NSSA External Type 2
External metric only
Treated like E2 but originates in NSSA
E2 — External Type 2
External metric only
Lowest preference
Designated Router and Backup Designated Router
Multi-access networks allow more than two routers to exist on a network segment. With OSPF when each router becomes neighbor of each router, it can flood more LSAs, we dont worry about the hellos since they are still sent to all ospf routers as they needed for 2 way neighborships, it is only the LSAs that can cause issues in n (n – 1) / 2 setup due to excessive traffic
Not just the network but having so many adjacencies per segment consumes more bandwidth, more CPU processing, and more memory to maintain each of the neighbor states.
One router on the network becomes a designated router DR and one router becomes BDR, all OSPF routers then become 2 way adjacent using hellos DROTHER but only fully adjacent with the DR and BDR by sending their full LSDB, this LSDB received by DR and BDR is then synced with all or rest of the OSPF routers, but all of this happens per subnet or per segment
DR/BDR election occurs with OSPF neighborship—specifically, during the last phase of the 2-Way neighbor state and just before the ExStart state
Router interface having OSPF priority of non-zero will attempts DR/BDR elections, if priority is 0 then that OSPF router “interface” (not the whole router) does not take part in DR/BDR elections
Default priority is 1, higher priority wins
If all OSPF routers on a multi-access segment (e.g., Ethernet) have the same priority, OSPF uses the highest Router ID (RID) as the tie-breaker to elect the DR and BDR.
Routers place their RID and also the priority inside hellos
The OSPF DR and BDR roles cannot be preempted but only upon the failure of router control plane
or
manual process restart from CLI
Wait timer
To ensure that all routers on a segment have fully initialized or booted into OS and running OSPF
OSPF initiates a wait timer when OSPF hello packets do not contain a DR/BDR router for a segment. The default value for the wait timer is the dead interval timer When the wait timer has expired, a router participates in the DR election.
The wait timer starts when OSPF first starts on an interface, so a router can still elect itself as the DR for a segment without other OSPF routers; it only waits until the wait timer expires
point-to-point link and has no DR/BDR
If all the OSPF routers have the same OSPF priority, and the next decision is to use the higher RID (and RID selection is also a per node’s local process, to find the highest IP on the loopback interfaces and if no loopback interfaces with IP, then highest IP address on the physical interfaces)
Increasing priority on one router increases its chances of becoming the DR or BDR since default priority on an OSPF interface is 1 and Remember that OSPF does not preempt the DR or BDR roles, so it might be necessary to restart the OSPF process on the current DR/BDR for the changes to take effect.
Setting an interface priority to 0 removes that interface from the DR/BDR election immediately.
OSPF Network Types
Not every transport or network is multiaccess
We have to determine the right network / media type and set OSPF network type based on that
Remember the rule for need of DR/BDR on the network, wherever B is then DR/BDR are needed such as “B”roadcast and non “B”roadcast
| Type | Description | DR/BDR Field in OSPF Hellos | Timers |
|---|---|---|---|
| Broadcast | Default setting on OSPF-enabled Ethernet links. | Yes | Hello: 10 Wait: 40 Dead: 40 |
| Nonbroadcast | Default setting on enabled OSPF Frame Relay main interface or Frame Relay multipoint sub-interfaces. | Yes | Hello: 30 Wait: 120 Dead: 120 |
| Point-to-point | Default setting on enabled OSPF Frame Relay point-to-point sub-interfaces. | No | Hello: 10Wait: 40Dead: 40 |
| Point-to-multipoint | Not enabled by default on any interface type. Interface is advertised as a host route (/32), and sets the next-hop address to the outbound interface. Primarily used for hub-and-spoke topologies. | No | Hello: 30 Wait: 120 Dead: 120 |
| Loopback | Default setting on OSPF-enabled loopback interfaces. Interface is advertised as a host route (/32). | N/A | N/A |
Broadcast
Broadcast networks are multi-access in that they are capable of connecting more than two devices, and broadcasts sent out one interface are capable of reaching all interfaces attached to that segment hence broadcast
ip ospf network broadcast overrides the automatically configured setting and statically sets an interface as an OSPF broadcast network type.
Nonbroadcast
Frame Relay, ATM, and X.25 are considered NBMA in that they can also connect more than two devices but some devices could be in different virtual circuits while in a same subnet
Virtual circuits may provide connectivity, but the topology may not be a full mesh and might only provide a hub-and-spoke topology.
Frame Relay interfaces set the OSPF network type to nonbroadcast by default. The hello protocol interval takes 30 seconds for this OSPF network type. Multiple routers can exist on a segment, so the DR functionality is used. Neighbors are statically defined with the neighbor ip-address command because multicast and broadcast functionality do not exist on this type of circuit. Configuring a static neighbor causes OSPF hellos to be sent using unicast.
command ip ospf network non-broadcast manually sets an interface as an OSPF nonbroadcast network type
R1
interface Serial 0/0
ip address 10.12.1.1 255.255.255.252
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip address 10.12.1.2 102
!
router ospf 1
router-id 192.168.1.1
neighbor 10.12.1.2
network 0.0.0.0 255.255.255.255 area 0R1# show ip ospf interface Serial 0/0 | include Type
Process ID 1, Router ID 192.168.1.1, Network Type
NON_BROADCAST, Cost: 64Point-to-Point Networks
Only two nodes can exist on this type of network medium, so OSPF does not waste CPU cycles on DR functionality. The hello timer is set to 10 seconds on OSPF point-to-point network types.
OSPF network type is set to point-to-point by default for serial interfaces (HDLC or PPP encapsulation), Generic Routing Encapsulation (GRE) tunnels, and point-to-point Frame Relay sub-interfaces
R1
interface serial 0/1
ip address 10.12.1.1 255.255.255.252
!
router ospf 1
router-id 192.168.1.1
network 0.0.0.0 255.255.255.255 area 0R2
interface serial 0/1
ip address 10.12.1.2 255.255.255.252
!
router ospf 1
router-id 192.168.2.2
network 0.0.0.0 255.255.255.255 area 0R1# show ip ospf interface s0/1 | include Type
Process ID 1, Router ID 192.168.1.1, Network Type POINT_TO_POINT, Cost: 64R2# show ip ospf interface s0/1 | include Type
Process ID 1, Router ID 192.168.2.2, Network Type POINT_TO_POINT, Cost: 64R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.2.2 0 FULL/ - 00:00:36 10.12.1.2 Serial0/1Point-to-point OSPF network types do not use a DR. Notice the hyphen (-) in the State field.
Interfaces using an OSPF P2P network type form an OSPF adjacency quickly because the DR election is bypassed, and there is no wait timer. “Ethernet interfaces” that are directly connected with only two OSPF speakers in the subnet could be changed to the OSPF point-to-point network type to form adjacencies more quickly and to simplify the SPF computation
command ip ospf network point-to-point manually sets an interface as an OSPF point-to-point network type.
Point-to-Multipoint Networks
Point-to-multipoint OSPF network type supports hub-and-spoke connectivity while using the same IP subnet and is commonly found in Frame Relay and Layer 2 VPN (L2VPN) topologies.
OSPF network type point-to-multipoint is not enabled by default for any medium. It requires manual configuration. A DR is not enabled for this OSPF network type, and the hello timer is set to 30 seconds.
Interfaces set for the OSPF point-to-multipoint network type add the interface’s IP address to the OSPF LSDB as a /32 network which means that this interface address will be advertised as /32 network and will be received by neighbors as /32 and routes received on neighbors through this router and neighbors will use this /32 interface as the next hop
Why? Because OSPF wants to treat each neighbour as a separate logical link, not part of a shared network. Using /32: Removes the idea of a shared subnet.
command ip ospf network point-to-multipoint manually sets an interface as an OSPF point-to-multipoint network type
R1
interface Serial 0/0
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial 0/0.123 multipoint
ip address 10.123.1.1 255.255.255.248
frame-relay map ip 10.123.1.2 102 broadcast
frame-relay map ip 10.123.1.3 103 broadcast
ip ospf network point-to-multipoint
!
router ospf 1
router-id 192.168.1.1
network 0.0.0.0 255.255.255.255 area 0R2
interface Serial 0/0
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial 0/1/0/0.123 multipoint
ip address 10.123.1.2 255.255.255.248
frame-relay map ip 10.123.1.1 201 broadcast
ip ospf network point-to-multipoint
!
router ospf 1
router-id 192.168.2.2
network 0.0.0.0 255.255.255.255 area 0R3
interface Serial 0/0
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial 0/0.123 multipoint
ip address 10.123.1.3 255.255.255.248
frame-relay map ip 10.123.1.1 301 broadcast
ip ospf network point-to-multipoint
!
router ospf 1
router-id 192.168.3.3
network 0.0.0.0 255.255.255.255 area 0R1# show ip ospf interface Serial 0/0.123 | include Type
Process ID 1, Router ID 192.168.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64R2# show ip ospf interface Serial 0/0.123 | include Type
Process ID 1, Router ID 192.168.2.2, Network Type POINT_TO_MULTIPOINT, Cost: 64R3# show ip ospf interface Serial 0/0.123 | include Type
Process ID 1, Router ID 192.168.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 64Notice that all three routers are on the same subnet, but R2 and R3 do not establish an adjacency with each other.
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.3.3 0 FULL/ - 00:01:33 10.123.1.3 Serial0/0.123
192.168.2.2 0 FULL/ - 00:01:40 10.123.1.2 Serial0/0.123R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 0 FULL/ - 00:01:49 10.123.1.1 Serial0/0.123R3# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 0 FULL/ - 00:01:46 10.123.1.1 Serial0/0.123R1# show ip route ospf | begin Gateway
Gateway of last resort is not set
O 10.123.1.2/32 [110/64] via 10.123.1.2, 00:07:32, Serial0/0.123
O 10.123.1.3/32 [110/64] via 10.123.1.3, 00:03:58, Serial0/0.123
192.168.2.0/32 is subnetted, 1 subnets
O 192.168.2.2 [110/65] via 10.123.1.2, 00:07:32, Serial0/0.123
192.168.3.0/32 is subnetted, 1 subnets
O 192.168.3.3 [110/65] via 10.123.1.3, 00:03:58, Serial0/0.123R2# show ip route ospf | begin Gateway
Gateway of last resort is not set
O 10.123.1.1/32 [110/64] via 10.123.1.1, 00:07:17, Serial0/0.123
O 10.123.1.3/32 [110/128] via 10.123.1.1, 00:03:39, Serial0/0.123
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/65] via 10.123.1.1, 00:07:17, Serial0/0.123
192.168.3.0/32 is subnetted, 1 subnets
O 192.168.3.3 [110/129] via 10.123.1.1, 00:03:39, Serial0/0.123R3# show ip route ospf | begin Gateway
Gateway of last resort is not set
O 10.123.1.1/32 [110/64] via 10.123.1.1, 00:04:27, Serial0/0.123
O 10.123.1.2/32 [110/128] via 10.123.1.1, 00:04:27, Serial0/0.123
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/65] via 10.123.1.1, 00:04:27, Serial0/0.123
192.168.2.0/32 is subnetted, 1 subnets
O 192.168.2.2 [110/129] via 10.123.1.1, 00:04:27, Serial0/0.123Loopback Networks
OSPF network type loopback is enabled by default for loopback interfaces and can be used only on loopback interfaces, always advertised with a /32 prefix length, even if the IP address configured on the loopback interface does not have a /32 prefix length.
R1interface Loopback0
ip address 192.168.1.1 255.255.255.0
interface Serial 0/1
ip address 10.12.1.1 255.255.255.252
!
router ospf 1
router-id 192.168.1.1
network 0.0.0.0 255.255.255.255 area 0RR2’s loopback interface is set to the OSPF point-to-point network type to ensure that R2’s loopback interface advertises the network prefix 192.168.2.0/24
R2
interface Loopback0
ip address 192.168.2.2 255.255.255.0
ip ospf network point-to-point
interface Serial 0/0
ip address 10.12.1.2 255.255.255.252
!
router ospf 1
router-id 192.168.2.2
network 0.0.0.0 255.255.255.255 area 0R1# show ip ospf interface Loopback 0 | include Type
Process ID 1, Router ID 192.168.1.1, Network Type LOOPBACK, Cost: 1R2# show ip ospf interface Loopback 0 | include Type
Process ID 1, Router ID 192.168.2.2, Network Type POINT_TO_POINT, Cost: 1R1# show ip ospf database router | I Advertising|Network|Mask
Advertising Router: 192.168.1.1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.1.1
(Link Data) Network Mask: 255.255.255.255
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.12.1.0
(Link Data) Network Mask: 255.255.255.0
Advertising Router: 192.168.2.2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.2.0
(Link Data) Network Mask: 255.255.255.0
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.12.1.0
(Link Data) Network Mask: 255.255.255.0Design difference between P2MP and NBMA and Why use where
NBMA
Frame Relay, DMVPN, MPLS
Like Ethernet segment without broadcast
DR/BDR election due to Ethernet like segment and because of “B”
Hub can become DR
NBMA can’t do broadcast or multicast (no 224.0.0.5/6).
Hellos and LSAs must be sent using unicast to neighbours.
Neighbors must be configured manually neighbor x.x.x.x
Both P2MP and NBMA offer single subnet WAN
Configured using command ip ospf network non-broadcast
In NBMA spoke to spoke become neighbors but by default, in a typical hub-and-spoke NBMA design (like Frame Relay), spokes do not become neighbors with each other, because they cannot directly communicate unless the underlying NBMA network provides full-mesh VC connectivity.
P2MP
Frame Relay, DMVPN, MPLS
Hub-and-spoke and the spokes do not fully mesh
Can work with (broadcast command) or without broadcast (default P2MP)
P2MP (with broadcast capable media) can discover neighbours dynamically via multicast
This allows simpler configuration vs NBMA with manual config for many spokes
No DR but bunch of P2P while HUB is P2MP
For example, hub router with 20 spokes across DMVPN or MPLS, spokes never talk directly.
Neighbors are configured manually
/32 Host routes P2P links
Both P2MP and NBMA offer single subnet WAN
P2MP is used over NBMA when there is no spoke to spoke communication allowed
Failure Detection
OSPF Dead interval timer, which defaults to four times the hello timer. Upon receipt of the hello packet from a neighboring router, the OSPF dead timer resets to the initial value, and then it starts to decrement again.
If a router does not receive a hello before the OSPF dead interval timer reaches 0, the neighbor state is changed to down. The OSPF router immediately sends out the appropriate LSA, reflecting the topology change, and the SPF algorithm processes on all routers within the area.
Changing the hello timer interval modifies the default dead interval, too. The OSPF hello timer is modified with the interface configuration submode command ip ospf hello-interval 1-65,535
You can change the dead interval timer to a value between 1 and 65,535 seconds. You change the OSPF dead interval timer by using the command ip ospf dead-interval 1-65,535 under the interface configuration submode.
show ip ospf interface shows timers
R1# show ip ospf interface | i Timer|line
Loopback0 is up, line protocol is up
GigabitEthernet0/2 is up, line protocol is up
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
GigabitEthernet0/1 is up, line protocol is up
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5Authentication
An attacker can forge OSPF packets or gain physical access to a network, manipulate the routing and take control of traffic
OSPF authentication is enabled on an interface-by-interface basis or for all interfaces in an area
You can set the password only as an interface parameter, and you must set it for every interface.
If you miss an interface, the default password is set to a null value.
OSPF supports two types of authentication:
Plaintext: This type of authentication provides little security, as anyone with access to the link can see the password by using a network sniffer.
You enable plaintext authentication for an OSPF area with the command area area-id authentication, then use the interface parameter command ip ospf authentication to set plaintext authentication only on that interface. You configure the plaintext password by using the interface parameter command ip ospf authentication-key password.
MD5 cryptographic hash: This type of authentication uses a hash, so the password is never sent out the wire. This technique is widely accepted as being the more secure mode. You enable MD5 authentication for an OSPF area by using the command area area-id authentication message-digest, and then the interface parameter command ip ospf authentication message-digest to set MD5 authentication for that interface. You configure the MD5 password with the interface parameter command ip ospf message-digest-key key-number md5 password.
MD5 authentication is a hash of the key number and password combined. If the keys do not match, the hash differs between the nodes. That is why keys much match between the nodes and this is the use of the keys
Area 12 uses plaintext authentication, and Area 0 uses MD5 authentication
R1 and R3 use interface-based authentication
R2 uses area-specific authentication
R1
interface GigabitEthernet0/0
ip address 10.12.1.1 255.255.255.0
ip ospf authentication
ip ospf authentication-key CISCO
!
router ospf 1
network 10.12.1.0 0.0.0.255 area 12R2
interface GigabitEthernet0/0
ip address 10.12.1.2 255.255.255.0
ip ospf authentication-key CISCO
!
interface GigabitEthernet0/1
ip address 10.23.1.2 255.255.255.0
ip ospf message-digest-key 1 md5 CISCO
!
router ospf 1
area 0 authentication message-digest
area 12 authentication
network 10.12.1.0 0.0.0.255 area 12
network 10.23.1.0 0.0.0.255 area 0R3
interface GigabitEthernet0/1
ip address 10.23.1.3 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
!
router ospf 1
network 10.23.1.0 0.0.0.255 area 0You verify the authentication settings by examining the OSPF interface without the brief option
R1# show ip ospf interface | include line|authentication|key
GigabitEthernet0/0 is up, line protocol is up
Simple password authentication enabledR2# show ip ospf interface | include line|authentication|key
GigabitEthernet0/1 is up, line protocol is up
Cryptographic authentication enabled
Youngest key id is 1
GigabitEthernet0/0 is up, line protocol is up
Simple password authentication enabledR3# show ip ospf interface | include line|authentication|key
GigabitEthernet0/1 is up, line protocol is up
Cryptographic authentication enabled
Youngest key id is 1OSPF uses six LSA types for IPv4 routing:
Type 1, router: LSAs that advertise prefixes within an area
Type 2, network: LSAs that indicate the routers attached to broadcast segment within an area
Type 3, summary: LSAs that advertise prefixes that originate from a different area
Type 4, ASBR summary: LSA used to locate the ASBR from a different area
Type 5, AS external: LSA that advertises prefixes that were redistributed in to OSPF
Type 7, NSSA external: LSA for external prefixes that were redistributed in a local NSSA area
LSA Types 1, 2, and 3 are used for building the SPF tree for intra-area and inter-area route routes.
LSA Types 4, 5, and 7 are related to external OSPF routes (that is, routes that were redistributed into the OSPF routing domain).
LSA Sequences
In OSPF, the LSA sequence number is used for versioning, and the originating router increments it each time it reoriginates (updates) the LSA
If a receiving router receives an LSA sequence that is greater than the one in the LSDB, it processes the LSA, If the LSA sequence number is lower than the one in the LSDB, the router deems the LSA old and discards it.
LSA Age and Flooding
Every local router keeps the LSA and also maintains the timer against that LSA called “age”, when LSA is first created in database, that “age” field is 0 but it start incrementing in the DB each second locally, once that age reaches 1800 seconds which is 30 mins, the originating router automatically generates a new copy of that LSA.
This is built into OSPF to keep the LSDB fresh and ensure routers don’t accidentally keep stale information forever.
Another LSA increment (over the links – inflight)
When a router forwards (floods) an LSA to a neighbour, the age increases by a small calculated delay
This accounts for:
- Link transmission delay
- Router processing time
In practice, this increment is small, but the LSA age always increases as it moves across the network.
If any LSA reaches 3600 seconds, it is considered expired or MaxAge.
If a router receives an LSA that has reached MaxAge (3600 seconds), it will reflood that LSA with LS age = 3600 to all its neighbors.
This behaviour ensures that every router, both downstream and upstream, deletes the LSA from its LSDB.
This flooding happens even if the router is not the original creator of the LSA.
Why flood the MaxAge LSA?
Because OSPF relies on synchronized LSDBs.
If one router deletes an LSA silently but others don’t, the network becomes inconsistent.
Router A (originator) publishes LSA
↓
Routers B, C, D store it
↓
LSA in Router D reaches 3600 seconds
↓
Router D floods LSA age = 3600 to neighbors (C)
↓
Router C deletes LSA, floods MaxAge to Router B
↓
Router B deletes LSA, floods MaxAge to Router A
↓
Router A deletes its own stale LSA
LSA Types
ABRs maintain a separate set of LSAs for each OSPF area
LSA Type 1: Router Link
A Type 1 LSA entry exists for each OSPF-enabled link (that is, an interface and its attached networks).
Type 1 LSAs are not advertised outside Area thus making the underlying topology in an area invisible to other areas.
R1# show ip ospf database
OSPF Router with ID (192.168.1.1) (Process ID 1)
Router Link States (Area 1234)
Link ID ADV Router Age Seq# Checksum Link count
192.168.1.1 192.168.1.1 14 0x80000006 0x009EA7 1
192.168.2.2 192.168.2.2 2020 0x80000006 0x00AD43 3
192.168.3.3 192.168.3.3 6 0x80000006 0x0056C4 2
192.168.4.4 192.168.4.4 61 0x80000005 0x007F8C 2Link ID
Identifies the object that the link connects to. It can refer to the neighboring router’s RID, the IP address of the DR’s interface, or the IP network address.
ADV Router
The OSPF router ID of the router that originated the LSA
AGE
The age of the LSA on the router on which the command is being run. Values over 1800 are expected to refresh soon.
Seq #
Sequence number for the LSA
Checksum
The checksum of the LSA to verify integrity during flooding.
Link Count
3 links → Router has three OSPF interfaces/networks it advertises.
If we explore this LSA further we will see networks mentioned inside it
This makes it functions just like a router LSA, router telling us how many links it has in a certain area
You can examine the Type 1 OSPF LSAs by using the command show ip ospf database router
R1# show ip ospf database router
! Output omitted for brevity
OSPF Router with ID (192.168.1.1) (Process ID 1)
Router Link States (Area 1234)
LS age: 352 <<< start of LSA
Options: (No TOS-capability, DC)
LS Type: Router Links <<< Type 1 LSA
Link State ID: 192.168.1.1 <<< how it shows in sh ip ospf database
Advertising Router: 192.168.1.1
LS Seq Number: 80000014
Length: 36
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.123.1.3
(Link Data) Router Interface address: 10.123.1.1
|
No hint of the network yet
TOS 0 Metrics: 1
LS age: 381
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 192.168.2.2
Advertising Router: 192.168.2.2
LS Seq Number: 80000015
Length: 60
Number of Links: 3
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 192.168.4.4
(Link Data) Router Interface address: 10.24.1.1
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.24.1.0
(Link Data) Network Mask: 255.255.255.248
TOS 0 Metrics: 64
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.123.1.3
(Link Data) Router Interface address: 10.123.1.2
TOS 0 Metrics: 1
LS age: 226
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 192.168.3.3
Advertising Router: 192.168.3.3
LS Seq Number: 80000014
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.3.3.0
(Link Data) Network Mask: 255.255.255.0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.123.1.3
(Link Data) Router Interface address: 10.123.1.3
TOS 0 Metrics: 1
LS age: 605
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 192.168.4.4
Advertising Router: 192.168.4.4
LS Seq Number: 80000013
Length: 48
Area Border Router <<< telling us that even though this
Number of Links: 2 is in our area but
this is an ABR with
one leg in our area
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 192.168.2.2
(Link Data) Router Interface address: 10.24.1.4
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.24.1.0
(Link Data) Network Mask: 255.255.255.248
TOS 0 Metrics: 64If a router is functioning as an ABR, an ASBR, or a virtual-link endpoint, the function is listed between the Length field and the Number of links field.
“show ip ospf database” Link ID can mean different things based the LSA type
Point-to-point link (IP address assigned)
Link type 1
Neighbor RID
Link to transit network
Link type 2
Interface address of the DR
Link to stub network
Link type 3
Network address
Virtual link
Link type 4
Neighbor RID
Transit link in router LSA shows DR and IP address facing DR
Point to point link in router LSA advertise two links
One link is the point-to-point link type that identifies the OSPF neighbor RID for that segment, and the other link is a stub network link that provides the subnet mask for that network
Stub Network in router LSA has no neighbors, Point-to-point and transit link types that did not become adjacent with another OSPF router are classified as a stub network link type
Secondary connected networks are always advertised as stub link types because OSPF adjacencies can never form on them
Just by using information from Router LSA type 1, we can build a topology
Notice that the three router links on R1, R2, and R3 (10.123.1.0) have not been directly connected yet.
Also see how topology uses Link ID and then its corresponding Link Data
R3 is elected as the DR (that is why Link ID is 10.123.1.3), and R2 is elected as the BDR
LSA Type 2: Network Link
A Type 2 LSA (network LSA) represents a multi-access network
DR always advertises the Type 2 LSA
identifies all the routers attached to that network segment.
If a DR has not been elected, a Type 2 LSA is not present in the LSDB
Type 2 LSAs are not flooded outside the originating OSPF area in an identical fashion to Type 1 LSAs.
R1# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.1.1) (Process ID 1)
..
Net Link States (Area 1234)
Link ID ADV Router Age Seq# Checksum
10.123.1.3 10.192.168.3.3 1752 0x80000012 0x00ADC5Type 2 LSA that is advertised by “R3” but show command is on R1
The network mask for the subnet is included in the Type 2 LSA
R1# show ip ospf database network
OSPF Router with ID (192.168.1.1) (Process ID 1)
Net Link States (Area 1234)
LS age: 356
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.123.1.3 (address of Designated Router)
Advertising Router: 192.168.3.3
LS Seq Number: 80000014
Checksum: 0x4DD
Length: 36
Network Mask: /24
Attached Router: 192.168.3.3
Attached Router: 192.168.1.1
Attached Router: 192.168.2.2Visualization of the Type 1 and Type 2 LSAs
When the DR changes for a network segment, a new Type 2 LSA is created, causing SPF to run again within the OSPF area.
Pseudonode because that box is considered a node in OSPF LSDB but it is not real node or router
LSA Type 3: Summary Link
Type 3 LSAs (summary LSAs) represent networks from other areas. The role of the ABRs is to participate in multiple OSPF areas and ensure that these Type 1 networks are reachable from other areas
As explained earlier, ABRs do not forward Type 1 or Type 2 LSAs into other areas. When an ABR receives a Type 1 LSA, it creates an equivalent Type 3 LSA
The ABR then advertises the Type 3 LSA into other areas
If an ABR receives a Type 3 LSA from Area 0 (backbone area), it regenerates a new Type 3 LSA for the nonbackbone area and lists itself as the advertising router with the additional cost metric
Type 1 LSAs exist only in the area of origination and convert to Type 3 when they cross the ABRs (R4 and R5).
The Type 3 LSAs show up under the appropriate area where they exist in the OSPF domain. For example, the 10.56.1.0 Type 3 LSA exists only in Area 0 and Area 1234 on R4.
R4# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.4.4) (Process ID 1)
..
Summary Net Link States (Area 0)
|
v
This just means that these are Type 1 LSAs of
foreign or remote areas in this area
Link ID ADV Router Age Seq# Checksum
10.3.3.0 192.168.4.4 813 0x80000013 0x00F373
10.24.1.0 192.168.4.4 813 0x80000013 0x00CE8E
10.56.1.0 192.168.5.5 591 0x80000013 0x00F181
10.123.1.0 192.168.4.4 813 0x80000013 0x005A97
..
Summary Net Link States (Area 1234)
|
v
This just means that these are Type 1 LSAs of
foreign or remote areas in this area
Link ID ADV Router Age Seq# Checksum
10.45.1.0 192.168.4.4 813 0x80000013 0x0083FC
10.56.1.0 192.168.4.4 813 0x80000013 0x00096BR5# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.5.5) (Process ID 1)
..
Summary Net Link States (Area 0)
|
v
This just means that these are Type 1 LSAs of
foreign or remote areas in this area
Link ID ADV Router Age Seq# Checksum
10.3.3.0 192.168.4.4 893 0x80000013 0x00F373
10.24.1.0 192.168.4.4 893 0x80000013 0x00CE8E
10.56.1.0 192.168.5.5 668 0x80000013 0x00F181
10.123.1.0 192.168.4.4 893 0x80000013 0x005A97
..
Summary Net Link States (Area 56)
|
v
This just means that these are Type 1 LSAs of
foreign or remote areas in this area
Link ID ADV Router Age Seq# Checksum
10.3.3.0 192.168.5.5 668 0x80000013 0x00F073
10.24.1.0 192.168.5.5 668 0x80000013 0x00CB8E
10.45.1.0 192.168.5.5 668 0x80000013 0x007608
10.123.1.0 192.168.5.5 668 0x80000013 0x005797The advertising router for Type 3 LSAs is the last ABR that advertises the prefix. The metric in the Type 3 LSA uses the following logic:
- If the Type 3 LSA is created from a Type 1 LSA, it is the total path metric to reach the originating router in the Type 1 LSA.
- If the Type 3 LSA is created from a Type 3 LSA (from Area 0), it is the total path metric to the ABR plus the metric in the original Type 3 LSA
R4# show ip ospf database summary 10.56.1.0
OSPF Router with ID (192.168.4.4) (Process ID 1)
Summary Net Link States (Area 0)
LS age: 754
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.56.1.0 (summary Network Number)
Advertising Router: 192.168.5.5
LS Seq Number: 80000013
Checksum: 0xF181
Length: 28
Network Mask: /24
MTID: 0 Metric: 1 <<< this is in Area 0
Summary Net Link States (Area 1234)
LS age: 977
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.56.1.0 (summary Network Number)
Advertising Router: 192.168.4.4
LS Seq Number: 80000013
Checksum: 0x96B
Length: 28
Network Mask: /24
MTID: 0 Metric: 2 <<< when sent to non Area 0
incrementedshows the Type 3 LSA for the Area 56 prefix (10.56.1.0/24) from R4’s LSDB. R4 is an ABR, and the information is displayed for both Area 0 and Area 1234. Notice that the metric increases in Area 1234’s LSA compared to in Area 0’s LSA.
R4’s perspective of the Type 3 LSA created by ABR (R5) vs Reality visualized below
R4 does not know if the 10.56.1.0/24 network is directly attached to the ABR (R5) or if it is multiple hops away (due to area obfuscation). R4 knows that its metric to the ABR (R5) is 1 and that the Type 3 LSA already has a metric of 1, so its total path metric to reach the 10.56.1.0/24 network is 2.
R3’s perspective of the Type 3 LSA created by the ABR (R4) for the 10.56.1.0/24 network vs reality visualised
R3 does not know if the 10.56.1.0/24 network is directly attached to the ABR (R4) or if it is multiple hops away (due to area obfuscation). R3 knows that its metric to the ABR (R4) is 65 and that the Type 3 LSA already has a metric of 2 (the metric R4 brings for network 10.56.1.0/24), so its total path metric is 67 to reach the 10.56.1.0/24 network
LSA Type 5: External Routes
When a route is redistributed into OSPF, the router is known as an autonomous system boundary router (ASBR). The external route is flooded throughout the entire OSPF domain (every area) as a Type 5 LSA (external LSAs).
Notice that the Type 5 LSA exists in all OSPF areas of the routing domain. Type 5 LSA is not regenerated unlike Type 4 instead only LSA Age is incremented
The link ID is the external network number, and the advertising router is the RID for the router originating the Type 5 LSA
R6# show ip ospf database
! Output omitted for brevity
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 192.168.6.6 11 0x80000001 0x000866 0R6# show ip ospf database external
OSPF Router with ID (192.168.6.6) (Process ID 1)
Type-5 AS External Link States
LS age: 720
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.16.6.0 (External Network Number )
Advertising Router: 192.168.6.6
LS Seq Number: 8000000F
Checksum: 0xA9B0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0R1# show ip ospf database external
OSPF Router with ID (192.168.1.1) (Process ID 1)
Type-5 AS External Link States
LS age: 778
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 172.16.6.0 (External Network Number )
Advertising Router: 192.168.6.6
LS Seq Number: 8000000F
Checksum: 0xA9B0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0LSA Type 4: ASBR Summary
A Type 4 LSA (ASBR summary LSA) locates the ASBR for a Type 5 LSA
Routers examine the Type 5 LSA, check to see whether the RID is in the local area (because if in local area then cost advertised can be believed for E1), but if the ASBR is not local, a mechanism is required to locate the ASBR or measure distance to ASBR (for cases where we have 2 competing routes, which both have ASBR in remote area for which we dont have a view of)
Type 4 LSAs provide a way for routers to locate the ASBR when the ASBR is in a different area
A Type 4 LSA is created by the first ABR, and it provides a summary route strictly for the ASBR of a Type 5 LSA
The metric for a Type 4 LSA uses the following logic:
- When the Type 5 LSA crosses the first ABR (Area 0 ***ABR*** Area 56) creates a Type 4 LSA with a metric set to the total path metric to the ASBR.
- When an ABR receives a Type 4 LSA from Area 0, the ABR creates a new Type 4 LSA with a metric set to the total path metric of the first ABR (Area 1234 ***ABR*** Area 0) plus the metric to ASBR in the original Type 4 LSA, (Cost to ASBR or type 4 LSA is not added through every router’s outgoing interface)
R4# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.4.4) (Process ID 1)
..
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.6.6 192.168.5.5 930 0x8000000F 0x00EB58
..
Summary ASB Link States (Area 1234)
Link ID ADV Router Age Seq# Checksum
192.168.6.6 192.168.4.4 1153 0x8000000F 0x000342R4# show ip ospf database asbr-summary
! Output omitted for brevity
OSPF Router with ID (192.168.4.4) (Process ID 1)
Summary ASB Link States (Area 0)
LS age: 1039
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 192.168.6.6 (AS Boundary Router address)
Advertising Router: 192.168.5.5
Length: 28
Network Mask: /0
MTID: 0 Metric: 1
Summary ASB Link States (Area 1234)
LS age: 1262
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 192.168.6.6 (AS Boundary Router address)
Advertising Router: 192.168.4.4
Length: 28
Network Mask: /0
MTID: 0 Metric: 2An ABR advertises only one Type 4 LSA for every ASBR, even if the ASBR advertises thousands of Type 5 LSAs
LSA Type 7: NSSA External Summary
A Type 7 LSA (NSSA external LSA) exists only in NSSAs where route redistribution is occurring.
An ASBR sitting on the edge of an NSSA Area injects external routes as Type 7 LSAs in an NSSA
The ABR does not advertise Type 7 LSAs outside the originating NSSA but it converts the Type 7 LSA into a Type 5 LSA
If the Type 5 LSA crosses Area 0, the second ABR creates a Type 4 LSA for the Type 5 LSA
R5 injects the Type 5 LSA (only) in Area 0, which propagates to Area 1234, and R4 creates the Type 4 LSA for Area 1234 and also forwards Type 5 (only LSA age is incremented).
R5# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.5.5) (Process ID 1)
..
Type-7 AS External Link States (Area 56) <<< Type 7
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 192.168.6.6 46 0x80000001 0x00A371 0
! Notice that no Type-4 LSA has been generated. Only the Type-7 LSA for Area 56
! and the Type-5 LSA for the other areas. R5 advertises the Type-5 LSA
Type-5 AS External Link States <<< converted to Type 5
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 192.168.5.5 38 0x80000001 0x0045DBR4# show ip ospf database
! Output omitted for brevity
OSPF Router with ID (192.168.4.4) (Process ID 1)
..
Summary ASB Link States (Area 1234) <<< Type 4
Link ID ADV Router Age Seq# Checksum
192.168.5.5 192.168.4.4 193 0x80000001 0x002A2C
Type-5 AS External Link States <<< for this Type 5
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 192.168.5.5 176 0x80000001 0x0045DB 0R5# show ip ospf database nssa-external
OSPF Router with ID (192.168.5.5) (Process ID 1)
Type-7 AS External Link States (Area 56)
LS age: 122
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 172.16.6.0 (External Network Number )
Advertising Router: 192.168.6.6
LS Seq Number: 80000001
Checksum: 0xA371
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.56.1.6
External Route Tag: 0LSA Type Visualization
Notice that the Type 2 LSAs are present only on the broadcast network segments
OSPF Stubby Areas
Stubby areas filter out external routes and even inter-area with some stub types – logic is to not have a massive Type 5 database on small routers, stub allows us to replace these massive type 5 in every area LSDB to be replaced with one external default route
OSPF stubby areas are identified by the area flag in the OSPF hello packet
Every router within an OSPF stubby area needs to be configured as a stub so that the routers can establish/maintain OSPF adjacencies
The following sections explain the four types of OSPF stubby areas in more detail:
- Stub areas
- Totally stubby areas
- Not-so-stubby areas (NSSAs)
- Totally NSSAs
Stub Areas
OSPF stub areas prohibit “Type 5” LSAs (external routes) and “Type 4” LSAs (ASBR summary LSAs) from entering the area at the ABR
When a Type 5 LSA reaches the ABR of a stub area, the ABR generates a default route for the stub via a Type 3 LSA
A Cisco ABR generates a default route when the area is configured as a stub and has an OSPF-enabled interface configured for Area 0
R3 and R4 before Area 34 is configured as a stub area, Notice the external 172.16.1.0/24
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:01:46, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:01:46, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:00:51, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:00:58, GigabitEthernet0/0
O E1 172.16.1.0 [110/23] via 10.34.1.3, 00:00:46, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:00:51, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:00:58, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:00:58, GigabitEthernet0/0All routers in the stub area must be configured as stubs, or an adjacency cannot form because the area type flags in the hello packets do not match
R3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router ospf 1
R3(config-router)# area 34 stubR4# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# router ospf 1
R4(config-router)# area 34 stub
The routing table from R3’s perspective is not modified as it receives the Type 4 and Type 5 LSAs from Area 0, But when the Type 5 LSA (172.16.1.0/24) reaches the R3 ABR, the R3 ABR generates a default route by using a Type 3 LSA. While R4 only receives Intra Area routes, Inter-Area route and Type 3 (not Type 5) the default route
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:03:10, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:03:10, GigabitEthernet0/1
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:03:10, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:03:10, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:01:57, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is 10.34.1.3 to network 0.0.0.0
O*IA 0.0.0.0/0 [110/2] via 10.34.1.3, 00:02:45, GigabitEthernet0/0
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:02:45, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:02:45, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:02:45, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:02:45, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:02:45, GigabitEthernet0/0Totally Stubby Areas
An OSPF totally stubby area prohibits Type 3 LSAs (inter-area), Type 4 LSAs (ASBR summary LSAs), and Type 5 LSAs (external routes) from entering the area at the ABR
When an ABR of a totally stubby area receives a Type 3 or Type 5 LSA, the ABR generates a default route for the totally stubby area.
In fact, an ABR for a totally stubby area advertises the default route into the totally stubby area
Assigning the interface acts as the trigger for the Type 3 LSA that leads to the generation of the default route
Only intra-area and default routes should exist within a totally stubby area.
Routing Tables of R3 and R4 Before the Totally Stubby Area
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:01:36, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:01:46, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:01:46, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:00:51, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:00:58, GigabitEthernet0/0
O E1 172.16.1.0 [110/23] via 10.34.1.3, 00:00:46, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:00:51, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:00:58, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:00:58, GigabitEthernet0/0ABRs of a totally stubby area have no-summary appended to the configuration, Member routers (non-ABRs) of a totally stubby area are configured the same as those in a stub area and do not need no-summary.
The command area area-id stub no-summary is configured under the OSPF process. The keyword no-summary does exactly what it states: It blocks all Type 3 (summary) LSAs going into the stub area, making it a totally stubby area.
R3# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router ospf 1
R3(config-router)# area 34 stub no-summaryR4# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# router ospf 1
R4(config-router)# area 34 stubRouting tables for R3 and R4 after Area 34 is converted to a totally stubby area, Notice that only the default route exists on R4
The routing table on R3 has not changed at all
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:02:34, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:02:34, GigabitEthernet0/1
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:02:34, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:02:34, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:03:23, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is 10.34.1.3 to network 0.0.0.0
O*IA 0.0.0.0/0 [110/2] via 10.34.1.3, 00:02:24, GigabitEthernet0/0Not-So-Stubby Areas
An OSPF not-so-stubby-area (NSSA) prohibits Type 5 LSAs from entering at the ABR but allows for redistribution of external routes into the NSSA and into Area 0
As the ASBR redistributes the route into OSPF in the NSSA, the ASBR advertises the route with a Type 7 LSA instead of a Type 5 LSA. When the Type 7 LSA reaches the ABR, the ABR converts the Type 7 LSA to a Type 5 LSA
The ABR does not automatically advertise a default route into an NSSA when a Type 5 or Type 7 LSA is blocked (because it might have its own NSSA based default route so it does not do it automatically, thinking may be it is not needed)
During configuration, an option exists to advertise a default route to provide connectivity to the blocked LSAs; in addition, other techniques can be used to ensure bidirectional connectivity.
Routing tables of R1, R3, and R4 before Area 34 is converted to an NSSA
R1# show ip route ospf | section 172.31
O E1 172.31.4.0 [110/23] via 10.12.1.2, 00:00:38, GigabitEthernet0/0R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O E1 172.31.4.0 [110/21] via 10.34.1.4, 00:01:12, GigabitEthernet0/0
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:01:12, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O E1 172.16.1.0 [110/23] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:02:28, GigabitEthernet0/0The command area area-id nssa [default-information-originate] is placed under the OSPF process on the ABR. All routers in an NSSA must be configured with the nssa option, or they do not become adjacent
A default route is not injected on the ABRs automatically for NSSAs, but the optional command default-information-originate can be appended to the configuration if a default route is needed in the NSSA.
R3# show run | section router ospf
router ospf 1
router-id 192.168.3.3
area 34 nssa default-information-originate
network 10.23.1.0 0.0.0.255 area 0
network 10.34.1.0 0.0.0.255 area 34
network 192.168.3.3 0.0.0.0 area 0R4# show run | section router ospf
router ospf 1
router-id 192.168.4.4
area 34 nssa
redistribute connected metric-type 1 subnets
network 10.34.1.0 0.0.0.255 area 34
network 192.168.4.4 0.0.0.0 area 34shows the routing tables of R3 and R4 after converting Area 34 to an NSSA
On R3, the previous external route from R1 still exists as an OSPF external Type 1 (O E1) route, and R4’s external route is now an OSPF external NSSA Type 1 (O N1) route
On R4, R1’s external route is no longer present. R3 is configured to advertise a default route, which appears as an OSPF external NSSA Type 2 (O N2) route.
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:04:13, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:04:13, GigabitEthernet0/1
O N1 172.31.4.0 [110/22] via 10.34.1.4, 00:03:53, GigabitEthernet0/0
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:04:13, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:04:13, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:03:53, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is 10.34.1.3 to network 0.0.0.0
O*N2 0.0.0.0/0 [110/1] via 10.34.1.3, 00:03:13, GigabitEthernet0/0
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:03:23, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:03:23, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:03:23, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:03:23, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:03:23, GigabitEthernet0/0Totally NSSAs
Totally NSSA block Type 3 and Type 5 LSAs and still provide the capability of redistributing external networks
When the ASBR redistributes the route into OSPF, the ASBR advertises the route with a Type 7 LSA. As the Type 7 LSA reaches the ABR, the ABR converts the Type 7 LSA to a Type 5 LSA.
When an ABR for a totally NSSA receives a Type 3 LSA from the backbone, the ABR generates a default route for the totally NSSA. When an interface on the ABR is assigned to Area 0, it acts as the trigger for the Type 3 LSA that leads to the default route generation within the totally NSSA.
R1’s, R3s, and R4’s Routing Tables Before Area 34 Is a Totally NSSA
R1# show ip route ospf | section 172.31
172.31.0.0/24 is subnetted, 1 subnets
O E1 172.31.4.0 [110/23] via 10.12.1.2, 00:00:38, GigabitEthernet0/0R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O E1 172.31.4.0 [110/21] via 10.34.1.4, 00:01:12, GigabitEthernet0/0
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:01:34, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:01:12, GigabitEthernet0/0R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/3] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O E1 172.16.1.0 [110/23] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.1.1 [110/4] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.2.2 [110/3] via 10.34.1.3, 00:02:28, GigabitEthernet0/0
O IA 192.168.3.3 [110/2] via 10.34.1.3, 00:02:28, GigabitEthernet0/0Member routers of a totally NSSA use the same configuration as members of an NSSA and do not need no-summary, ABRs of a totally NSSA area have no-summary appended to the configuration. The command area area-id nssa no-summary is configured under the OSPF process.
R3# show run | section router ospf 1
router ospf 1
router-id 192.168.3.3
area 34 nssa no-summary
network 10.23.1.0 0.0.0.255 area 0
network 10.34.1.0 0.0.0.255 area 34
network 192.168.3.3 0.0.0.0 area 0R4# show run | section router ospf 1
router ospf 1
router-id 192.168.4.4
area 34 nssa
redistribute connected metric-type 1 subnets
network 10.34.1.0 0.0.0.255 area 34
network 192.168.4.4 0.0.0.0 area 34Routing tables of R3 and R4 after Area 34 is converted into a totally NSSA.
R3 detects R1’s redistributed route as an O E1 (Type 5 LSA) and R4’s redistributed route as an O N1 (Type 7 LSA)
R3# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:02:14, GigabitEthernet0/1
O E1 172.16.1.0 [110/22] via 10.23.1.2, 00:02:14, GigabitEthernet0/1
O N1 172.31.4.0 [110/22] via 10.34.1.4, 00:02:04, GigabitEthernet0/0
O IA 192.168.1.1 [110/3] via 10.23.1.2, 00:02:14, GigabitEthernet0/1
O 192.168.2.2 [110/2] via 10.23.1.2, 00:02:14, GigabitEthernet0/1
O 192.168.4.4 [110/2] via 10.34.1.4, 00:02:04, GigabitEthernet0/0Notice that only the default route exists on R4
R4# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is 10.34.1.3 to network 0.0.0.0
O*IA 0.0.0.0/0 [110/2] via 10.34.1.3, 00:04:21, GigabitEthernet0/0OSPF Path Selection
OSPF executes Dijkstra’s shortest path first (SPF) algorithm to create a loop-free topology of shortest paths, All routers use same SPF algorithm and come up with their own topology of shortest paths.
Path selection prioritizes paths in the following order:
- O
- O IA
- N1
- E1
- N2
- E2
Link Costs
Router’s outgoing interface cost is used to accumulate path cost
but every interface is given its cost based on below formula
Or OSPF cost can be set manually with the command ip ospf cost 1-65535 under the interface.
Each OSPF link cost (interface cost) is stored in LSAs.
LSAs use a 16-bit field for cost → maximum value = 65,535.
But OSPF does not store the full path cost in the LSA, instead 1 – 65535 limited costs are assigned to interfaces in LSDB topology and then cumulative path cost is calculated each router when each router executes its own SPF, Therefore, the total path metric can exceed 65,535, even though each individual link cost cannot.
The default reference bandwidth is 100 Mbps due to legacy OSPF design
There is no differentiation in the link cost associated with a Fast Ethernet interface and a 10-Gigabit Ethernet interface which is bad because there is a huge difference and should be differentiated
Changing the reference bandwidth to a higher value allows for differentiation of cost between higher-speed interfaces.
Under the OSPF process, the command auto-cost reference-bandwidth bandwidth-in-mbps changes the reference bandwidth for all OSPF interfaces associated with that process.
If the reference bandwidth is changed on one router, then the reference bandwidth should be changed on all OSPF routers to ensure that SPF uses the same logic to prevent routing loops. It is a best practice to set the same reference bandwidth for all OSPF routers.
NX-OS uses a default reference cost of 40,000 Mbps
Intra-area Routes
OSPF intra-area routes (Type 1 and 2 LSAs) are always preferred over inter-area routes (Type 3 LSAs).
R1 is calculating the route to the 10.4.4.0/24 network. Instead of taking the faster Ethernet connection (R1→R2→R4), R1 takes the path across the slower serial link to R4 (R1→R3→R4) because that is the intra-area path.
R1# show ip route 10.4.4.0
Routing entry for 10.4.4.0/24
Known via "ospf 1", distance 110, metric 111, type intra area
Last update from 10.13.1.3 on GigabitEthernet0/1, 00:00:42 ago
Routing Descriptor Blocks:
* 10.13.1.3, from 10.34.1.4, 00:00:42 ago, via GigabitEthernet0/1
Route metric is 111, traffic share count is 1Inter-area Routes
R1 is computing the path to R6. R1 uses the path R1→R3→R5→R6 because its total path metric is 35 as compared to the metric of 40 for the R1→R2→R4→R6 path
External Route Selection
External routes are classified as Type 1 or Type 2. The main differences between Type 1 and Type 2 external OSPF routes are as follows:
- Type 1 routes are preferred over Type 2 routes.
- The Type 1 metric equals the redistribution metric plus the total path metric to the ASBR. In other words, as the LSA propagates away from the originating ASBR, the metric increases.
- The Type 2 metric equals only the redistribution metric. The metric is the same for the router next to the ASBR as for the router 30 hops away from the originating ASBR. This is the default external metric type that OSPF uses.
E1 and N1 External Routes
External OSPF Type 1 route calculation involves the redistribution metric plus the lowest path metric to reach the ASBR that advertised the network. Type 1 path metrics are lower for routers closer to the originating ASBR, whereas the path metric is higher for a router 10 hops away from the ASBR.
If there is a tie in the path metric, both routes are installed into the RIB. If the ASBR is in a different area, the path of the traffic must go through Area 0. An ABR does not install O E1 and O N1 routes into the RIB at the same time. O N1 is always given preference for a typical NSSA, and its presence prevents the O E1 from being installed on the ABR.
E2 and N2 External Routes
External OSPF Type 2 routes do not increment in metric, regardless of the path metric to the ASBR. If there is a tie in the redistribution metric, the router compares the metric to the ASBR that advertised the network, and the path with lower metric to ASBR wins. If there is a tie in metric to ASBR, both routes are installed into the routing table
An ABR does not install O E2 and O N2 routes into the RIB at the same time. O N2 is always given preference for a typical NSSA, and its presence prevents the O E2 from being installed on the ABR.
show ip ospf border-routersTypes of routers shown in above command
- ASBRs — Autonomous System Boundary Routers
(Routers that inject external routes into OSPF using E1/E2 LSAs) - ABRs — Area Border Routers
(Routers that connect one OSPF area to another and generate Type-3/4/5 LSAs)
172.16.0.0/24 has a metric of 20
R1→R2→R4→R6 path is 31, and the forwarding metric of the R1→R3→R5→R7 path is 30. R1 installs the R1→R3→R5→R7 path into the routing table.
R1# show ip route 172.16.0.0
Routing entry for 172.16.0.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 30
Last update from 10.13.1.3 on GigabitEthernet0/1, 00:12:40 ago
Routing Descriptor Blocks:
* 10.13.1.3, from 192.168.7.7, 00:12:40 ago, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1The logic of choosing an O Nx route over an O Ex route is defined in RFC 3101. Choosing an O Nx is the current default for IOS XE implementations. RFC 1583 prefers an O Ex route over an O Nx route. RFC 1583 path selection can be enabled with the command compatible rfc1583
Equal-Cost Multipathing
If OSPF calculates same path cost for multiple prefixes, they are all installed in the routing table. The default max ECMP paths is four. The default ECMP setting can be overwritten with the command maximum-paths maximum-paths under the OSPF process to modify the default setting.
Summarization
OSPF LSDB size can become large even after splitting OSPF into multiple areas due to large number of Type 3 LSAs and also the Type 5 LSAs
Summarization is a method of shrinking the LSDB
Newer routers have more memory and faster processors than do older ones, but because all routers have an identical copy of the LSDB, an OSPF area needs to accommodate the smallest and slowest router in that area.
Summarization of routes also helps SPF calculations run faster.
A router that has 10,000 network routes will take longer to run the SPF calculation than a router with 500 network routes. Because all routers within an area must maintain an identical copy of the LSDB
Summarization only occurs between areas on the ABRs.
Summarization can protect against the changes in prefixes outside the area for the summarized prefixes because the smaller prefixes are hidden.
shows the networks in Area 1 being summarized at the ABR into the aggregate 10.1.0.0/18 prefix
If the 10.1.12.0/24 link fails, all the routers in Area 1 still run the SPF calculation, but routers in Area 0 are not affected because the 10.1.13.0/24 and 10.1.34.0/24 networks are not known outside Area 1.
Inter-area summarization reduces the number of Type 3 LSAs that an ABR advertises into an area when it receives Type 1 LSAs. The network summarization range is associated with a specific source area for Type 1 LSAs.
When a Type 1 LSA in the summarization range reaches the ABR from the source area, the ABR creates a Type 3 LSA for the summarized network range. The ABR suppresses the more specific Type 3 LSAs.
Type 1 LSAs (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) being summarized into one Type 3 LSA
Summarization works only on Type 1 LSAs and is normally configured (or designed) so that summarization occurs as routes enter the backbone from nonbackbone areas Area x -> Area 0.
At the time of this writing, IOS XE routers set the default metric for the summary LSA to be the lowest metric associated with an LSA
However, the summary metric can statically be set as part of the configuration
R1 summarizes three prefixes with various path costs. The 172.16.3.0/24 prefix has the lowest metric, so that metric will be used for the summarized route.
OSPF behaves similar to Enhanced Interior Gateway Routing Protocol (EIGRP) in that it checks every prefix in the summarization range when a matching Type 1 LSA is added or removed. If a lower metric is available, the summary LSA is advertised with the newer metric; if the lowest metric is removed, a newer and higher metric is identified, and a new summary LSA is advertised with the higher metric.
Configuration of Inter-area Summarization
You define the summarization range and associated area by using the command area area-id range network subnet-mask [advertise | not-advertise] [cost metric] under the OSPF process.
The default behavior is to advertise the summary prefix, so the keyword advertise is not necessary. Appending cost metric to the command statically sets the metric on the summary route.
Routing Table Before OSPF Inter-area Route Summarization
R3# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:02:22, GigabitEthernet0/1
O IA 172.16.1.0 [110/3] via 10.23.1.2, 00:02:12, GigabitEthernet0/1
O IA 172.16.2.0 [110/3] via 10.23.1.2, 00:02:12, GigabitEthernet0/1
O IA 172.16.3.0 [110/3] via 10.23.1.2, 00:02:12, GigabitEthernet0/1router ospf 1
router-id 192.168.2.2
area 12 range 172.16.0.0 255.255.0.0 cost 45
network 10.12.0.0 0.0.255.255 area 12
network 10.23.0.0 0.0.255.255 area 0
R2 summarizes them into a single summary route, 172.16.0.0/16 static cost of 45 is added to the summary route to reduce CPU load if any of the three networks flap.
R3’s routing table shows that smaller component routes were suppressed while summary route is being advertised
Notice in this output that the path metric is 46 whereas previously the metric for the 172.16.1.0/24 network was 3.
R3# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.12.1.0/24 [110/2] via 10.23.1.2, 00:02:04, GigabitEthernet0/1
O IA 172.16.0.0/16 [110/46] via 10.23.1.2, 00:00:22, GigabitEthernet0/1The ABR performing inter-area summarization installs discard routes, which are routes to the Null0 interface that match the summarized network. Discard routes prevent routing loops where portions of the summarized network range do not have a more specific route in the RIB. The administrative distance (AD) for the OSPF summary discard route for internal networks is 110, and it is 254 for external networks.
R2# show ip route ospf | begin Gateway
Gateway of last resort is not set
O 172.16.0.0/16 is a summary, 00:03:11, Null
O 172.16.1.0/24 [110/2] via 10.12.1.1, 00:01:26, GigabitEthernet0/0
O 172.16.2.0/24 [110/2] via 10.12.1.1, 00:01:26, GigabitEthernet0/0
O 172.16.3.0/24 [110/2] via 10.12.1.1, 00:01:26, GigabitEthernet0/0External Summarization
During OSPF redistribution, external routes are redistributed into the OSPF domain as Type 5 or Type 7 LSAs (NSSA). External summarization reduces the number of external LSAs in an OSPF domain
An external summarization route is configured on the ASBR router, and a smaller component route generates a Type 5/Type 7 external summary route, and the smaller component routes in the summary route are suppressed.
Routing Table Before External Summarization
R5# show ip route ospf | begin Gateway
! Output omitted for brevity
Gateway of last resort is not set
O IA 10.3.3.0/24 [110/67] via 10.45.1.4, 00:01:58, GigabitEthernet0/0
O IA 10.24.1.0/29 [110/65] via 10.45.1.4, 00:01:58, GigabitEthernet0/0
O IA 10.123.1.0/24 [110/66] via 10.45.1.4, 00:01:58, GigabitEthernet0/0
O E2 172.16.1.0 [110/20] via 10.56.1.6, 00:01:00, GigabitEthernet0/1
O E2 172.16.2.0 [110/20] via 10.56.1.6, 00:00:43, GigabitEthernet0/1
..
O E2 172.16.14.0 [110/20] via 10.56.1.6, 00:00:19, GigabitEthernet0/1
O E2 172.16.15.0 [110/20] via 10.56.1.6, 00:00:15, GigabitEthernet0/1R6
router ospf 1
router-id 192.168.6.6
summary-address 172.16.0.0 255.255.240.0
redistribute eigrp 1 subnets
network 10.56.1.0 0.0.0.255 area 56R5# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.3.3.0/24 [110/67] via 10.45.1.4, 00:04:55, GigabitEthernet0/0
O IA 10.24.1.0/29 [110/65] via 10.45.1.4, 00:04:55, GigabitEthernet0/0
O IA 10.123.1.0/24 [110/66] via 10.45.1.4, 00:04:55, GigabitEthernet0/0
172.16.0.0/20 is subnetted, 1 subnets
O E2 172.16.0.0 [110/20] via 10.56.1.6, 00:00:02, GigabitEthernet0/1R5# show ip route 172.16.0.0 255.255.240.0
Routing entry for 172.16.0.0/20
Known via “ospf 1”, distance 110, metric 20, type extern 2, forward metric 1
Last update from 10.56.1.6 on GigabitEthernet0/1, 00:02:14 ago
Routing Descriptor Blocks:
* 10.56.1.6, from 192.168.6.6, 00:02:14 ago, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1The summarizing ASBR installs a discard route to Null0 that matches the summary route as part of a loop-prevention mechanism and it will be seen on router that is doing summarization in this case R6
R6# show ip route ospf | begin Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
O IA 10.3.3.0/24 [110/68] via 10.56.1.5, 00:08:36, GigabitEthernet0/1
O IA 10.24.1.0/29 [110/66] via 10.56.1.5, 00:08:36, GigabitEthernet0/1
O IA 10.45.1.0/24 [110/2] via 10.56.1.5, 00:08:36, GigabitEthernet0/1
O IA 10.123.1.0/24 [110/67] via 10.56.1.5, 00:08:36, GigabitEthernet0/1
172.16.0.0/16 is variably subnetted, 15 subnets, 3 masks
O 172.16.0.0/20 is a summary, 00:03:52, Null0ABRs for NSSAs act as ASBRs when a Type 7 LSA is converted to a Type 5 LSA. External summarization can be performed on ABRs only when they match this scenario.
Discontiguous Network and Virtual links
Above is a topology with mistake in design, where R2 and R4 are technically ABRs connected to Area 0 but this will not work, this is called discontiguous network. OSPF can catch this mistake because of all seeing LSDB
Most people would assume that R1 would learn about the route learned by Area 45 because R4 is an ABR. However, they would be wrong. ABRs follow three fundamental rules for creating Type 3 LSAs:
Type 1 LSAs received from an area create Type 3 LSAs into backbone area and nonbackbone areas.
Type 3 LSAs received from Area 0 are created for the nonbackbone area.
Type 3 LSAs received from a nonbackbone area are only inserted into the LSDB for the source area. An ABR does not create a Type 3 LSA for the other areas (including a segmented Area 0).
When suspect, make sure that every ABR is touching Area 0 where all other Aera 0 routers show to be part of it, In above topology only R2 will find itself in the Area 0 and also R4 will only see itself as part of Area 0
Create a detection strategy in lab and practice against that
Virtual Links
OSPF virtual links provide a method to overcome discontiguous networks
Virtual Links are not just used for discontiguous Area 0s but it is also used to connect a topology in which Area 0 <–R100–> Area 1 <–R101–> Area 2, R101 ABR is deprived of Area 0
Area 0 can be extended to remote Areas
in above topology Area 12 and Area 45 were not orphaned
Area 12 , Area 0 and Area 234 kept working as R2 ABR has Area 0
Similarly Area 45 , Area 0 and Area 234 kept working as R4 ABR has Area 0
But Area 12 routes will not be learned by Area 45 and Area 45 routes will not be learned by Area 12 R2’s Area 0 and R4’s Area 0 are not same, practically preventing both from being in same Area 0
Virtual links are built between routers in the same area
The area in which the virtual link endpoints are established is known as the transit area
The virtual link can be one hop away or multiple hops away from the remote device between the ABRs
The virtual link is built using Type 1 LSAs
virtual links cannot be formed on any OSPF stubby areas
Area 234 cannot be an OSPF stub area. Or in this example Area 0 <–> Area 1 <–> Area 2 , Area 1 cannot be stub area
After Virtual Link configuration both Area 0 will become one Area 0 with 2x subnets 10.2.2.0/24 and 10.4.4.0/24 in Area 0
Think of virtual link being in Area 0, so once virtual link is established between ABRs, ABR that was not part of Area 0 will become part of Area 0 with one link in Area 0 which is virtual link
R2
router ospf 1
router-id 192.168.2.2
area 234 virtual-link 192.168.4.4 <<< like tunnel endpoint
network 10.2.2.2 0.0.0.0 area 0
network 10.12.1.2 0.0.0.0 area 12
network 10.23.1.2 0.0.0.0 area 234R4
router ospf 1
router-id 192.168.4.4
area 234 virtual-link 192.168.2.2 <<< like tunnel endpoint
network 10.4.4.4 0.0.0.0 area 0
network 10.34.1.4 0.0.0.0 area 234
network 10.45.1.4 0.0.0.0 area 45Interface cost for a virtual link cannot be set or dynamically generated as the metric for the intra-area distance between the two virtual link endpoints.
R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 192.168.4.4 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 234, via interface GigabitEthernet0/1
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Adjacency State FULL (Hello suppressed)
Index 1/1/3, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msecR4# show ip ospf virtual-links
! Output omitted for brevity
Virtual Link OSPF_VL0 to router 192.168.2.2 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 234, via interface GigabitEthernet0/0
Topology-MTID Cost Disabled Shutdown Topology Name
0 2 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:08
Adjacency State FULL (Hello suppressed)Notice that the cost here is 2, which accounts for the metrics between R2 and R4
OSPF Virtual Link as an OSPF Interface
R4# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/2 1 0 10.4.4.4/24 1 DR 0/0
VL0 1 0 10.34.1.4/24 2 P2P 1/1
Lo0 1 34 192.168.4.4/32 1 DOWN 0/0
Gi0/1 1 45 10.45.1.4/24 1 BDR 1/1
Gi0/0 1 234 10.34.1.4/24 1 BDR 1/1A Virtual Link Displayed as an OSPF Neighbor
R4# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.2.2 0 FULL/ - - 10.23.1.2 OSPF_VL0
192.168.5.5 1 FULL/DR 00:00:34 10.45.1.5 GigabitEthernet0/1
192.168.3.3 1 FULL/DR 00:00:38 10.34.1.3 GigabitEthernet0/0R1’s and R5’s Routing Tables After the Virtual Link Is Created
R1# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.2.2.0/24 [110/2] via 10.12.1.2, 00:00:10, GigabitEthernet0/0
O IA 10.4.4.0/24 [110/4] via 10.12.1.2, 00:00:05, GigabitEthernet0/0
O IA 10.23.1.0/24 [110/2] via 10.12.1.2, 00:00:10, GigabitEthernet0/0
O IA 10.34.1.0/24 [110/3] via 10.12.1.2, 00:00:10, GigabitEthernet0/0
O IA 10.45.1.0/24 [110/4] via 10.12.1.2, 00:00:05, GigabitEthernet0/0R5# show ip route ospf | begin Gateway
Gateway of last resort is not set
O IA 10.2.2.0/24 [110/4] via 10.45.1.4, 00:00:43, GigabitEthernet0/1
O IA 10.4.4.0/24 [110/2] via 10.45.1.4, 00:01:48, GigabitEthernet0/1
O IA 10.12.1.0/24 [110/4] via 10.45.1.4, 00:00:43, GigabitEthernet0/1
O IA 10.23.1.0/24 [110/3] via 10.45.1.4, 00:01:48, GigabitEthernet0/1
O IA 10.34.1.0/24 [110/2] via 10.45.1.4, 00:01:48, GigabitEthernet0/1ssh not enabled in EVENG-PRO
ssh was not working on the eveng-pro server
so I went to server screen directly and
ssh root@192.168.0.219
above ssh connection attempt gave error:
failed to restart ssh.service: unit ssh.service is masked
This means that ssh service is masked
systemctl status sshto fix it:
systemctl unmask ssh
systemctl enable ssh
systemctl restart sshSDA LM3 – Topology & Software Image Management
Videos
Topology & Software Image Management
SWIM – Software Image Management
you can only start tagging devices one you have uploaded the image, because we have virtual C9Kv images there is no .bin or .smu images available for them, from ths point on we will have screenshots from lab minutes
One image can be marked as golden image per device type either at the global level or at the site level, then any device that is not running that golden image will be marked as out of compliance
DNAC also supports auto clean up where it cleans up older image files
Using image column and version column with (Latest) means that these are the latest images, these images with (Latest) are being displayed from cisco.com and we can click on star icon to make them golden image
Making image golden enforces that image on that hardware model
Same thing can be repeated for different chassis or hardware types, their recommended Latest images can be marked as golden images
bundle mode images can be pulled from device and made golen image while for install mode we cannot pull from device and mark the image as golden image, instead we can either download from Cisco.com using gui or import image from file
Small “Verified” shows up next to image that shows that DNAC has downloaded the image, clicking that image makes it golden pretty fast because image is already on the DNAC server
Now making an image golden makes it same for all devices of same hardware model same across different “Roles” and all locations (Globally) and sometimes you may not want that, you can click on edit icon in device role column and set golden image per hardware model per device role, such as all “C9300” / “Access” to have a specific image or you can even have golden image per hardware model per role per location – but first you must remove the golden image from global level and then set it on site level, there is no concept of override here, either set at global level or set at all sites independently
Next step is to see which devices are not in compliance and upgrade them in provision > OS image column
DNAC validates Flash, RAM and Reboot required
SMU(0) means that there is no SMU for this image version
one big improvement in version 2.1 is that you can download image from local server instead of DNAC over the WAN
“Provision > provision device” pushes the remaining config as config assigned during assignment of device to site is not full config, full config is deployed when device is provisioned
Mark for replacement is when we have to RMA the device
Compliance > Run Compliance, this is manual trigger of the compliance and checks if device has golden image and if startup-config is same running-config etc
As devices are discovered in DNAC, it is also added in ISE
In ISE live logs we can see entries for devices authenticating to ISE for Trust Sec Device authentication
BGP
BGP
AS autonomous system, collection of router under a domain
An organization requiring connectivity to the Internet must obtain an ASN.
ASNs were originally 2 bytes (in the 16-bit range), 65,534 ASNs.
Due to exhaustion, ASN field expanded to accommodate 4 bytes (in the 32-bit range), This allows for 4,294,967,295 unique ASNs
https://ipwithease.com/basic-understanding-of-4-byte-asn/
Private ASN 16-bit range as 64512 to 65534
Public ASN 16-bit range 1 through 64511
Private ASN 32-bit range as 4200000000 to 4294967294
in 4 bytes ASN 0 – 65535 AS numbers are same as they were with 2 byte AS. These AS numbers help in interoperability between AS using 2 byte ASNs and AS using 4 byte ASNs.
4 Byte AS representation can be done in 3 ways as listed below:
- asplain – simple decimal representation of the ASN. For example, ASN 7747 will be represented as 7747, while 123456 will be represented as 123456.
- asdot+ – breaks the number up in two 16-bit values as low-order and high-order, separated by a dot. All the 2-byte ASNs can be represented in the low-order value. For example, ASN 65535 will be 0.65535, 65536 will be 1.0, 65537 will be 1.1 and so on. The last ASN 4294967296 will be 65535.65535.
- asdot – it is a mixture of asplain and asdot+. Any ASN in the 2-byte range is represented as asplain and any ASN above the 2-byte range is represented as asdot+. For example, 65535 will be 65535 while 65536 will be 1.0. Cisco uses this form of implementation.
It is significant to understand the interoperability of the 2 Byte AS number with the 4 Byte AS number.
4 byte AS support is advertised via BGP capability negotiation. Speakers who support 4-byte AS are known as New-BGP speakers & those who do not are known as Old-BGP speakers, it includes its 4-byte ASN in the Capability advertisement
No support / backwards compatibility scenario
If one neighbor or router is very old and it does not respond to 4-byte ASN capability, in this case new BGP speaker can bring up session with this very old router using a reserved 2 byte ASN called AS_TRANS (AS23456)
Because AS_TRANS AS23456 is reserved, no Old-BGP speaker can use it as its own ASN; only New-BGP speakers can use it.
New BGP Speaker to new BGP Speaker advertise routes using 4 byte ASN but new BGP Speaker to old BGP speaker
AS_PATH
- Any 4-byte ASN in the AS_PATH is replaced with AS_TRANS (23456) so the old router can “parse” it.
AS4_PATH (optional transitive attribute)
- The real 4-byte ASNs are preserved in the AS4_PATH attribute.
- Old routers ignore AS4_PATH.
- New routers later reconstruct the correct AS_PATH using AS4_PATH.
When an Old BGP Speaker advertises routes with AS4_PATH and AS_PATH attributes to a New BGP Speaker, the New BGP Speaker uses both attributes to reconstruct the path: AS4_PATH for 4-byte ASNs and AS_PATH for 2-byte ASNs by replacing 4-byte ASN with an AS_TRANS. In this way, the AS_PATH shows the correct number of hops
AS4_AGGREGATOR
A new attribute AS4_AGGREGATOR is introduced for similar reasons. If the New BGP Speaker has to send the AGGREGATOR attribute towards old speaker neighbor and if the aggregating ASN is a 4-byte ASN, then the speaker constructs the AS4_AGGREGATOR attributes by copying the attribute length and attribute value from the AGGREGATOR attribute, places the attribute length and attribute value in the AS4_AGGREGATOR attribute, and replaces the 4-byte ASN with AS_TRANS ASN.
BGP Peering
BGP peering is also called BGP session
There 2 types of peering,
iBGP peering and eBGP peering
ibgp can be like pseudowires
iBGP: Sessions established with a router that are in the same AS or that participate in the same BGP confederation
eBGP: Sessions established with a BGP router that are in a different AS
BGP does not use hello packets to discover neighbors
BGP was designed as an inter-autonomous routing protocol, implying that neighbor adjacencies should not change frequently and are coordinated.
BGP uses TCP port 179 to communicate with other routers
Relying on TCP allows for handling of fragmentation, sequencing, and reliability (acknowledgment and retransmission)
Most recent implementations of BGP set the do-not-fragment (DF) bit to prevent fragmentation and rely on path MTU discovery PMTUD https://learn.anasather.uk/ccie-misc/ccie-everything-else/
Multihop BGP peerings
BGP uses TCP that can cross boundaries unlike IGP which use link local multicast to form neighbors, BGP can form neighbor adjacencies that are directly connected or adjacencies that are multiple hops away.
BGP neighbors connected to the same network use the ARP table to locate the IP address of the peer.
Multi-hop BGP sessions require routing table information for finding the IP address of the peer.
A default route is not sufficient to establish a multi-hop BGP session.
Multi-hop sessions require that the router use an underlying route installed in the RIB (static or from any routing protocol) to establish the TCP session with the remote endpoint
If that neighbor’s IP isn’t specifically resolvable in the routing table (e.g., via a static route or an IGP-learned route), BGP won’t even attempt to start the TCP connection.
BGP Messages
OUNK
| Type | Name | Functional Overview |
|---|---|---|
| 1 | OPEN | Sets up and establishes BGP adjacency |
| 2 | UPDATE | Advertises, updates, or withdraws routes, CRUD |
| 3 | NOTIFICATION | Indicates an error condition to a BGP neighbor |
| 4 | KEEPALIVE | Ensures that BGP neighbors are still alive |
OPEN
OPEN message is used to establish adjacency,
Session capabilities are exchanged in open messages.
OPEN message contains following:
BGP version
ASN
Hold time
RID etc
Hold time: The hold time field in OPEN messages sets hold timer in seconds,
When establishing a BGP session, the routers use the smaller hold time value between the two routers.
The hold time value must be at least 3 seconds,
the hold time is set to 0 to disable KEEPALIVE messages.
For Cisco routers, the default hold time is 180 seconds.
BGP identifier RID: The BGP router ID (RID) is a 32-bit unique number that identifies the BGP router in the advertised prefixes.
The RID is used as a loop-prevention mechanism for routers advertised within an autonomous system.
The RID can be set manually or dynamically for BGP, setting manually is much stable way.
A nonzero value must be set in order for routers to become neighbors.
Dynamic RID allocation logic uses the highest IP address of any up loopback interfaces. If there is not an up loopback interface, then the highest IP address of any active up interfaces becomes the RID
To ensure that the RID does not change, a static RID is assigned (typically represented as an IPv4 address that resides on the router, such as a loopback address). Any IPv4 address can be used, including IP addresses not configured on the router
KEEPALIVE
KEEPALIVE messages are exchanged between neighbors, by default every 60 seconds, “3rd of the default Hold timer 180” seconds
If the hold time is set to 0, no KEEPALIVE messages are also sent between the BGP neighbors.
BGP keepalive timer and hold timer can be set at the process level or per neighbor session.
UPDATE
An Update can either advertise routes or withdraw routes
Prefixes that need to be withdrawn are advertised in the WITHDRAWN ROUTES field of the UPDATE message
Update message also serves as a keepalive as well,
Upon receipt of an UPDATE or KEEPALIVE, the hold timer resets to the initial value,
If the hold timer reaches zero, the BGP session is torn down, routes from that neighbor are removed, and an appropriate update route withdraw message is sent to other BGP neighbors for the affected prefixes
Notification
A Notification message is sent when an error is detected with the BGP session,
such as a hold timer expiring,
neighbor capabilities changing,
or a BGP session reset being requested.
Notification causes the BGP connection to close.
Notification message is basically a signal to neighbor to initiate session shutdown
BGP Neighbor States
BGP FSM
- Idle
- Connect
- Active
- OpenSent
- OpenConfirm
- Established
Idle
-BGP Process start
-BGP Process starts listening on TCP 179
-BGP tries to move to next state: connect
-In case any issues revert it back to idle – set ConnectRetry timer to 60 seconds, this time must count to 0 before any connection try can be made – ConnectRetry basically a delay timer
-Further failures to leave the Idle state result in the ConnectRetry timer doubling in length
Connect
-BGP initiates the TCP connection 3 way handshake
-If the TCP connection fails, the state changes to Active
-If the three-way TCP handshake completes,
-sends the OPEN message to the neighbor,
-moves to the OpenSent state
R1# show tcp brief
TCB Local Address Foreign Address (state)
F6F84258 10.12.1.1.179 10.12.1.2.59884 ESTAB
R2# show tcp brief
TCB Local Address Foreign Address (state)
EF153B88 10.12.1.2.59884 10.12.1.1.179 ESTABActive
-In the Active state, BGP starts a new three-way TCP handshake.
-If this attempt for TCP connection fails, the state moves back or downgrades to the Connect state
-If a connection is established,
-an OPEN message is sent,
-the hold timer is set to 4 minutes (longer hold time because of issues and hence Active state, longer hold time means that neighbor’s presence will not be checked quicker)
-and the state moves to OpenSent.
OpenSent
-OPEN message has been sent from the originating router and is awaiting an OPEN message from the other router.
-When the originating router receives the OPEN message from the other router, local OPEN and received OPEN message are checked for following:
-BGP versions must match
-The source IP address of the OPEN message must match what is configured for the neighbor
-The AS number must match what is configured for the neighbor
-RID must be unique
-Security parameters (such as password and time-to-live [TTL]) must qualify.
Hold times are compared, lowest hold time is used
Keepalive is sent
Connection state is then moved to OpenConfirm
If an error is found in the OPEN message, a NOTIFICATION message is sent, and the state is moved back to Idle.
OpenConfirm
In OpenConfirm state, BGP waits for a KEEPALIVE or NOTIFICATION message – so 2 way can be confirmed
Upon receipt of a neighbor’s KEEPALIVE, the state is moved to Established
If
-hold timer expires,
-a stop event occurs,
-a NOTIFICATION message is received
the state is moved to Idle
Established
BGP session is established
BGP neighbors exchange routes through UPDATE messages. As UPDATE and KEEPALIVE messages are received, the hold timer is reset.
If the hold timer expires, BGP moves the neighbor back to the Idle state and send a withdraw to other neighbors for routes learned through the now idle neighbor
BGP PA
BGP associates attributes with each network path / route and it is called its Path Attributes, which can also be considered as qualities of the path, such as AS Path shows the length of path and ASs the traffic will traverse, metric is cost associated with path – tells us about the thinking of admin assigning initial cost , weight to the path
These Path Attributes are of 4 different types:
Well-known mandatory
Well known man
Well-known attributes must be recognized by all BGP implementations – because it is well known and known by every BGP module that is written
Mandatory as well – mandatory attributes must be included with every prefix advertisement;
Well-known discretionary
well-known discretionary attributes may or may not be included with the prefix advertisement and can be skipped in sending of an update
Optional transitive
Optional attributes do not have to be recognized by all BGP implementations – BGP module writers can fully skip it as it is optional
Optional attributes can be transitive and stay with the route advertisement from AS to AS
Optional non-transitive
Some optional PAs are non-transitive and cannot be shared from AS to AS.
AS_PATH for Loop Prevention
AS_Path is used as a loop-prevention mechanism in BGP
BGP is a path vector routing protocol and does not contain a complete topology of the network, as do link-state routing protocols, BGP behaves like distance vector protocols
The BGP attribute AS_Path is a “well-known mandatory” attribute and includes a complete list of all the ASNs that the prefix advertisement has traversed from its source AS
“If a BGP router receives a prefix advertisement with its AS listed in AS_Path, it discards the prefix because the router thinks the advertisement forms a loop“
Multi-Protocol BGP (MP-BGP)
Originally BGP was designed around IPv4 but later on Multi-Protocol BGP (MP-BGP) allowed other protocols to be carried as well and that allowed BGP to carry (Address Family) AFI such as IPv6
An address family correlates to a specific network protocol, such as IPv4 or IPv6, and additional granularity is provided through a subsequent address family identifier (SAFI), such as unicast or multicast in that protocol
Multiprotocol BGP (MP-BGP) carries separate path attributes (PAs) for Multi protocol MP_REACH_NLRI and MP_UNREACH_NLRI than IPv4 based BGP, These PA attributes are held inside BGP update messages and that is why BGP can be used for different address families or protocols, that facilitates addresses just like IPv4 , IPv6 , Multicast and even MAC addresses. Address family maintains a separate database and configuration for each protocol under same BGP session.
Address family needs to be activated on peer
An address family must be activated for a BGP peer in order for BGP to initiate a session with that peer
IOS XE activates the IPv4 address family by default. This simplifies the configuration in an IPv4 environment, command no bgp default ipv4-unicast disables the automatic activation of the IPv4 AFI
Multiple Address families per neighbor
BGP Session parameters are configured such as neighbor IP , ASN , authentication , keepalive timers , source IP etc
but address family related configuration such as Network commands and summarization occur within the address family because IPv4 unicast and IPv6 multicast cannot have same configuration, although these 2 different AFI and SAFI can belong to same neighbor
Specifying the source interface
neighbor x.x.x.x update-source <interface> only changes the source IP address used in BGP packets. It does not change the actual outgoing interface used to send the packets. Outgoing interface can only be changed or dictated with static or dynamic route for that neighbor
BGP Authentication
BGP supports authentication with MD5 in order to prevent manipulation of BGP packets
BGP Configuration
R1 (Default IPv4 Address-Family Enabled)
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
neighbor 10.12.1.2 password CISCOBGP
neighbor 10.12.1.2 timers 10 40R2 (Default IPv4 Address-Family Disabled)
router bgp 65200
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.12.1.1 password CISCOBGP
neighbor 10.12.1.1 timers 15 50
!
address-family ipv4
neighbor 10.12.1.1 activateUse show commands with AFI and SAFI
R1# show bgp ipv4 unicast summary
BGP router identifier 192.168.1.1, local AS number 65100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.12.1.2 4 65200 8 9 1 0 0 00:05:23 0
| | | |
| | | |
Number of messages received from peer and queued to be processed
| | |
| | |
Number of messages queued to be sent to the peer
| |
| |
Length of time the BGP session is established
|
|
Current BGP peer state or the number of prefixes received from the peerUp/Down column indicates that the BGP session is up for over 5 minutes.
R2# show bgp ipv4 unicast neighbors 10.12.1.1
! Output omitted for brevity
! The first section provides the neighbor's IP address, remote-as, indicates if
! the neighbor is 'internal' or 'external', the neighbor's BGP version, RID,
! session state, and timers.
BGP neighbor is 10.12.1.1, remote AS65100, external link
BGP version 4, remote router ID 192.168.1.1
BGP state = Established, up for 00:01:04
Last read 00:00:10, last write 00:00:09, hold is 40, keepalive is 13 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
! This second section indicates the capabilities of the BGP neighbor and
! address-families configured on the neighbor.
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received <<<
Address family IPv4 Unicast: advertised and received <<<
Enhanced Refresh Capability: advertised <<<
Multisession Capability:
Stateful switchover support enabled: NO for session 1 <<<
Message statistics:
InQ depth is 0
OutQ depth is 0
! This section provides a list of the BGP packet types that have been received
! or sent to the neighbor router.
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 0
Keepalives: 2 2
Route Refresh: 0 0
Total: 4 3
Default minimum time between advertisement runs is 0 seconds
! This section provides the BGP table version of the IPv4 Unicast address-
! family. The table version is not a 1-to-1 correlation with routes as multiple
! route change can occur during a revision change. Notice the Prefix Activity
! columns in this section.
For address family: IPv4 Unicast
Session: 10.12.1.1
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 1, Advertise bit 0
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- ------- <<<
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
! This section indicates that a valid route exists in the RIB to the BGP peer IP
! address, provides the number of times that the connection has established and
! time dropped, since the last reset, the reason for the reset, if path-mtu-
! discovery is enabled, and ports used for the BGP session.
Address tracking is enabled, the RIB does have a route to 10.12.1.1 <<<
Connections established 2; dropped 1
Last reset 00:01:40, due to Peer closed the session <<<
Transport(tcp) path-mtu-discovery is enabled <<<
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Minimum incoming TTL 0, Outgoing TTL 255 <<<
Local host: 10.12.1.2, Local port: 179
Foreign host: 10.12.1.1, Foreign port: 56824BGP Adj tables
BGP uses three tables for maintaining the network paths and path attributes (PAs)
There are 3 different ways of learning a route
-Network command
-Learned from neighbor
-Redistribution into BGP
Adj-RIB-in: Contains the routes in original form (that is, from before inbound route policies were processed). The table is purgeable and is purged after all route policies are processed to save memory. After all routes have been fed through local policies it is emptied out
Loc-RIB:
-Loc-RIB contains routes after applying import policy, import policy only applies to routes learned from neighbors) Routes injected with the network command or redistributed – do not go through inbound policy – Locally-originated routes do go through best-path selection, but not through inbound policy + when a route comes from network statement then RIB check is made and only added in loc-RIB if there is same route with same subnet mask in RIB or routing table
-Routes collected in Loc-RIB are not the best routes and hence can contain multiple routes to a prefix
-contains routes that are originated locally and learned from neighbors.
-this table is “show ip bgp”
-after storing the routes here a validity check is performed, next-hop address in route if resolvable in the RIB then route is valid – and route is marked valid ” * “
-after valid routes are determined, these routes are passed through BGP best path algorithm and best routes is selected for “a prefix” and marked best with ” > ” – creating symbol of ” *> ” (valid + best)
Star means valid and not best
> means best
-Install the best-path route into the RIB
-After you enter a BGP network statement, the BGP process searches the global RIB for an exact network match. The network can be a connected network, a secondary connected network, or any route from a routing protocol.
-After verifying that the network statement matches a route in the RIB, the prefix is installed into the Loc-RIB table. As the BGP prefix is installed into the Loc-RIB, the following BGP PAs are set, depending on the RIB prefix type:
Connected network: The next-hop BGP attribute is set to 0.0.0.0, the BGP Origin attribute is set to i (for IGP), and the BGP weight is set to 32,768.
Static route or routing protocol: The next-hop BGP attribute is set to the next-hop IP address in the RIB, the BGP Origin attribute is set to i (for IGP), the BGP weight is set to 32,768, and the multi-exit discriminator (MED) is set to the IGP metric.
Remember best from > symbol, which means use this > route
Adj-RIB-out: Contains the routes after outbound route policies have been processed
This is a per neighbor table
By default, BGP only advertises the best path to other BGP peers
Advertise the route to BGP peers. If the route’s next-hop BGP PA is 0.0.0.0, the next-hop address is changed to the IP address of the BGP session.
It enables a network engineer to view routes advertised to a specific router using command show bgp afi safi neighbors ip-address advertised-routesMultiple BGP route sources
R1 already eBGP with R2
R1 has multiple routes learned from static routes, EIGRP, and OSPF
All the routes in R1’s routing table can be advertised into BGP, regardless of the source routing protocol.
Loopback networks are added as network statement except OSPF one, loopback learned over OSPF is redistributed instead
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
address-family ipv4 unicast
neighbor 10.12.1.2 activate
network 10.12.1.0 mask 255.255.255.0
network 192.168.1.1 mask 255.255.255.255
network 192.168.3.3 mask 255.255.255.255
network 192.168.4.4 mask 255.255.255.255
redistribute ospf 1Redistributing routes learned from an IGP into BGP is completely safe; however, redistributing routes learned from BGP into an IGP should be done with caution. BGP is designed for large scale and can handle a routing table the size of the Internet (940,000+ prefixes), whereas IGPs could have stability problems with fewer than 20,000 routes.
Origin code is IGP (for routes learned from the network statement) or incomplete (redistributed)
R1# show bgp ipv4 unicast
BGP table version is 9, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 0.0.0.0 0 32768 i
* 10.12.1.2 0 0 65200 i
*> 10.15.1.0/24 0.0.0.0 0 32768 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*> 192.168.2.2/32 10.12.1.2 0 0 65200 i
! The following route comes from EIGRP and uses a network statement
*> 192.168.3.3/32 10.13.1.3 3584 32768 i
! The following route comes from a static route and uses a network statement
*> 192.168.4.4/32 10.14.1.4 0 32768 i
! The following route was redistributed from OSPF
*> 192.168.5.5/32 10.15.1.5 11 32768 ?if the LocPrf (Local Preference) attribute is not shown in the BGP table output, that means:The Local Preference is 100 by default, Cisco only displays non-default local preference values in the BGP table
R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 i
*> 0.0.0.0 0 32768 i
*> 10.15.1.0/24 10.12.1.1 0 0 65100 ?
*> 192.168.1.1/32 10.12.1.1 0 0 65100 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i
*> 192.168.3.3/32 10.12.1.1 3584 0 65100 i
*> 192.168.4.4/32 10.12.1.1 0 0 65100 i
*> 192.168.5.5/32 10.12.1.1 11 0 65100 ?If multiple paths exist for the same prefix, only the first prefix is listed and other paths leave an empty space in the output
* valid paths
> best paths
Next hop is also a PA attribute
Metric – MED optional non-transitive BGP path attribute used in the BGP best-path algorithm for that specific path.
Optional = routers are not required to understand or use the attribute.
Non-transitive = the attribute must not be passed beyond the neighboring AS.
AS X sends a route with a MED to AS Y.
AS Y does NOT pass that MED on when advertising the route to any other AS (AS Z, etc.).
The MED is only meaningful between two directly connected ASes — it influences which entry point the neighbor should use, not the entire global internet
LocPrf – Local preference, a well-known discretionary path attribute used in the BGP best-path algorithm for that specific path.
Weight – A locally significant Cisco-defined attribute used in the BGP best-path algorithm for that specific path.
Path – AS_Path, a well-known mandatory BGP path attribute used for loop prevention and in the BGP best-path algorithm for that specific path.
Origin – Origin, a well-known mandatory BGP path attribute used in the BGP best-path algorithm. The value i represents an IGP, e is for EGP, and ? is for a route that was redistributed into BGP.
R1# show bgp ipv4 unicast 10.12.1.0
BGP routing table entry for 10.12.1.0/24, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65200
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (192.168.1.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
rx pathid: 0, tx pathid: 0x0Paths: (2 available, best #2)
Provides a count of BGP paths in the BGP Loc-RIB table and identifies the path selected as the BGP best path.
Advertised to update-groups
BGP neighbors are consolidated into BGP update groups. If a path is not advertised, Not advertised to any peer is displayed.
65200 (1st path)
Local (2nd path)
This is the AS_Path for the path as it was received or whether the prefix was locally advertised.
10.12.1.2 from 10.12.1.2 (192.168.2.2)
| | |
| | |
next hop | |
| |
advertising neighbor |
|
|
RID of the advertising neighborThe first entry lists the IP address of the next hop for the prefix.
The from field lists the IP address of the advertising neighbor. (The field could change when an external path is learned from an iBGP peer.)
The number in parentheses is the BGP identifier (RID) for the node.
Origin
Origin is well-known mandatory attribute that states the mechanism for advertising this path. In this instance, it is an internal path.
metric 0
Displays the optional non-transitive BGP attribute MED, also known as the BGP metric.
localpref 100
Displays the well-known discretionary BGP attribute Local Preference.
valid
Displays the validity of this path.
External (1st path)
Local (2nd path)
Displays how the path was learned: internal, external, or local.
R1# show bgp ipv4 unicast neighbors 10.12.1.2 advertised-routes
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 0.0.0.0 0 32768 i
*> 10.15.1.0/24 0.0.0.0 0 32768 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*> 192.168.3.3/32 10.13.1.3 3584 32768 i
*> 192.168.4.4/32 10.14.1.4 0 32768 i
*> 192.168.5.5/32 10.15.1.5 11 32768 ?
Total number of prefixes 6R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 0.0.0.0 0 32768 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i
Total number of prefixes 2R1# show bgp ipv4 unicast summary
! Output omitted for brevity
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.12.1.2 4 65200 11 10 9 0 0 00:04:56 2eBGP and iBGP
Internal BGP (iBGP):
in the same AS
or in same BGP confederation
iBGP learned routes are assigned AD of 200
External BGP (eBGP):
in a different AS
eBGP learned routes are assigned AD of 20
iBGP
Need for iBGP is needed when transit connectivity is needed or multi-homing is needed
AS 65200 provides transit connectivity to AS 65100 and AS 65300
R2 could form an iBGP session directly with R4
but R3 would not know where to forward traffic when traffic from either AS reaches R3
You might assume that redistributing the BGP table into an IGP overcomes the problem, but this not a viable solution, incase the BGP table is way larger than IGP can handle:
Scalability: IGPs cannot scale to that level of routes.
Routing: Link-state protocols and distance vector routing protocols use metric as the primary method for routing, while BGP uses multiple steps to identify the best path, The best path from BGP perspective could be longer, which would normally be deemed suboptimal from an IGP’s perspective.
Path attributes: All the BGP path attributes cannot be maintained within IGP protocols, upon redistribution into IGP, PA are lost
Solution to above problem is iBGP on all routers R2, R3 and R4 also called full mesh iBGP, that will allow proper forwarding of traffic
Above was just an example scenario, Enterprise organizations are consumers and should not provide transit connectivity between autonomous systems across the Internet, only service providers do.
BGP synchronization
In early iBGP deployments where the AS was used as a transit AS, network prefixes would commonly be redistributed into the IGP, To ensure full connectivity in the transit AS, BGP would use synchronization. BGP synchronization is the process of verifying that the BGP route existed in the IGP before the route could be advertised to an eBGP peer. BGP synchronization is no longer a default and is not commonly used
iBGP Full Mesh
iBGP peers do not prepend their ASN to AS_Path.
No other method exists for detecting loops with iBGP sessions so writers of BGP prohibit the advertisement of a route received from an iBGP peer to another iBGP peer.
RFC 4271 states that all BGP routers in a single AS must be fully meshed to provide a complete loop-free routing table
R1 advertises the 10.1.1.0/24 prefix to R2, which is processed and inserted into R2’s BGP table. R2 does not advertise the 10.1.1.0/24 route to R3 because it received the route from an iBGP peer R1
To resolve this issue, “R1 must form a multi-hop iBGP session with R3” so that R3 can receive the 10.1.1.0/24 route directly from R1
R1 and R3 either need a static route to the remote peering transit nets or R2 can advertise the 10.12.1.0/24 and 10.23.1.0/24 networks into BGP, if you think that R1’s 10.12.1.0/24 will not be passed by R2 to R3 but R1 did not advertise 10.12.1.0/24 instead R2 did, so 10.12.1.0/24 will be passed to R3 by R2
Need for peering using loopbacks
R1, R2, and R3 are a full mesh of iBGP sessions peered by transit links.
In the event of a link failure on the 10.13.1.0/24 network
R3’s BGP session with R1 will drop
R3 loses connectivity to the 10.1.1.0/24 network, even though R1 and R3 could communicate through R2 (through a multi-hop path).
This loss of connectivity occurs because iBGP does not advertise routes learned from another iBGP peer
You can overcome this issue by advertising the loopback into IGP and then creating BGP peering between loopback addresses
-loopback interface is virtual and always stays up
-Flexibility to failure: In the event of link failure, the session stays intact, and the IGP finds another path to the loopback address
-multi-hop iBGP session
10.13.1.0/24 link fails. R1 and R3 still maintain BGP session connectivity by reaching each other’s loopback through R2, R2 will simply route the BGP packets between R1 and R3 without taking part in that BGP session
R1 (Default IPv4 Address Family Enabled)
router ospf 1
network 10.12.0.0 0.0.255.255 area 0
network 10.13.0.0 0.0.255.255 area 0
network 192.168.1.1 0.0.0.0 area 0
!
router bgp 65100
network 10.1.1.0 mask 255.255.255.0
neighbor remote-as 192.168.2.2 65100
neighbor 192.168.2.2 update-source Loopback0
neighbor remote-as 192.168.3.3 65100
neighbor 192.168.3.3 update-source Loopback0
!
address-family ipv4
neighbor 192.168.2.2 activate
neighbor 192.168.3.3 activateR2 (Default IPv4 Address Family Disabled)
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
network 192.168.2.2 0.0.0.0 area 0
!
router bgp 65100
no bgp default ipv4-unicast
neighbor remote-as 192.168.1.1 65100
neighbor 192.168.1.1 update-source Loopback0
neighbor remote-as 192.168.3.3 65100
neighbor 192.168.3.3 update-source Loopback0
!
address-family ipv4
neighbor 192.168.1.1 activate
neighbor 192.168.3.3 activateas side effect of using loopback interfaces for peering is that next hop addresses are loopback addresses and recursive lookup is performed to find the outgoing interface
Another side effect that can happen is that if loopbacks are advertised It end up providing automatic load balancing if there are multiple equal-cost paths through the IGP to the loopback address (but only for iBGP)
eBGP
eBGP peerings
-AS is different from the AS configured locally in bgp router command
-The time-to-live (TTL) on eBGP packets is set to 1. BGP packets drop in transit if a multi-hop BGP session is attempted. The TTL on iBGP packets is set to 255, which allows for multi-hop sessions by default
-The advertising router modifies the BGP next hop for updates to the IP address sourcing the BGP connection
-The advertising router prepends its ASN to the existing AS_Path
-most recent AS is always prepended (the furthest to the left) since AS path is right to left
-The receiving router verifies that the AS_Path does not contain an ASN that matches the local routers. BGP discards the update if it fails the AS_Path loop-prevention check.
In above picture we can see ebgp peering and ibgp full mesh peering
Next hop issue for routes from eBGP to iBGP
As an eBGP prefix is advertised to an iBGP neighbor from local router, a route may not pass validity check because of next-hop reachability check and that route might be advertised from local router to first iBGP peer but not any further from that iBGP peer because that first iBGP peer considers route to be invalid due to next hop validity check failure
Because (local router) iBGP peer do not modify the next-hop address and when that foreign next hop address of eBGP router is passed to first iBGP peer and because that iBGP peer is not aware of that foreign address (next hop validity check which is first step in BGP best path selection fails), it is not advertised further to other iBGP peers as it is not even a valid route let alone best route.
The next-hop address must be resolvable in the RIB in order for it to be valid and advertised to other BGP peers.
Notice that the BGP best-path symbol (>) is missing for the 192.168.4.4/32 prefix on R2 and for the 192.168.1.1/32 prefix on R3.
R1’s BGP table is missing the 192.168.4.4/32 route because the route did not pass R2’s next-hop accessibility check, preventing the execution of the BGP best-path algorithm
R4 advertised the route to R3 with the next-hop address 10.34.1.4, and R3 advertised the route to R2 with the next-hop address 10.34.1.4. R2 does not have a route for the 10.34.1.4 IP address and deems the next hop inaccessible. The same logic applies to R1’s 192.168.1.1/32 route when advertised toward R4.
R3# show bgp ipv4 unicast 192.168.1.1
BGP routing table entry for 192.1681.1/32, version 2
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65100
10.12.1.1 (inaccessible) from 10.23.1.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, internalTo correct the issue, we can advertise those peering links using either below methods:
- IGP advertisement (Remember to use the passive interface to prevent an accidental adjacency from forming. Most IGPs do not provide the filtering capability provided by BGP.)
- Advertisement of the networks into BGP
or we could change next hop using next-hop-self, which is much better solution due to scalability as shown below
next-hop-self
Imagine that a service provider network has 500 routers, and every router has 200 eBGP peering links. To ensure that the next-hop address is reachable to the iBGP peers, the provider needs the advertisement of 100,000 peering networks in BGP or an IGP consuming router resources
using next-hop-self on ibgp neighbor we can achieve modification of that foreign ebgp peer’s address to its ibgp session address towards that ibgp peer
The next-hop-self feature only modifies prefixes going from ebgp peers to iBGP peers by default, but using the command next-hop-self [all] modifies the next-hop address on prefixes learned from iBGP to iBGP peers
R2 (Default IPv4 Address-Family Enabled)
router bgp 65200
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65200
neighbor 10.23.1.3 next-hop-selfR3 (Default IPv4 Address-Family Disabled)
router bgp 65200
no bgp default ipv4-unicast
neighbor 10.23.1.2 remote-as 65200
neighbor 10.34.1.4 remote-as 65400
!
address-family ipv4
neighbor 10.23.1.2 activate
neighbor 10.23.1.2 next-hop-self
neighbor 10.34.1.4 activate
iBGP Scalability Solutions
The inability of BGP to advertise a route learned from one iBGP peer to another iBGP peer can lead to scalability issues within an AS. The formula n(n − 1)/2 provides the number of sessions required, where n represents the number of routers. A full mesh topology of 5 routers requires 10 sessions, and a topology of 10 routers requires 45 sessions
Route Reflectors
The router that is reflecting routes is known as a route reflector (RR),
the router that is receiving reflected routes is a route reflector client.
This reflector model is like an OSPF DR concept but for neighborships and not full sync, instead of all iBGP routers making adjacency with every other router, one router makes iBGP peering with all the routers
But there are few rules to follow
- Rule 1: If an RR receives an NLRI from a non-RR client, the RR advertises the NLRI to an RR client. It does not advertise the NLRI to a non-RR client.
- Rule 2: If an RR receives an NLRI from an RR client, it advertises the NLRI to RR clients and non-RR clients.
- Rule 3: If an RR receives a route from an eBGP peer, it advertises the route to RR clients and non-RR clients.
remember that RR clients receive in all scenarios / rules
Only Route Reflector is configured with RR configuration, and RR clients do not need to modify configuration, they just need to make iBGP peering with route reflecting RR router
BGP route reflector is an address family command like other loc-RIB commands
BGP route reflection is specific to each address family.
The command neighbor ip-address route-reflector-client is used under the neighbor address family configuration.
R1 is a route reflector client to R2, and R4 is a route reflector client to R3. R2 and R3 have a normal iBGP peering
You can have a gap in between 2 RRs in your design
R1 (Default IPv4 Address-Family Enabled)
router bgp 65100
network 10.1.1.0 mask 255.255.255.0
redistribute connected
neighbor 10.12.1.2 remote-as 65100R2 (Default IPv4 Address-Family Enabled)
router bgp 65100
redistribute connected
neighbor 10.12.1.1 remote-as 65100
neighbor 10.12.1.1 route-reflector-client
neighbor 10.23.1.3 remote-as 65100R3 (Default IPv4 Address-Family Disabled)
router bgp 65100
no bgp default ipv4-unicast
neighbor 10.23.1.2 remote-as 65100
neighbor 10.34.1.4 remote-as 65100
!
address-family ipv4
redistribute connected
neighbor 10.23.1.2 activate
neighbor 10.34.1.4 activate
neighbor 10.34.1.4 route-reflector-clientR4 (Default IPv4 Address-Family Disabled)
router bgp 65100
no bgp default ipv4-unicast
neighbor 10.34.1.3 remote-as 65100
!
address-family ipv4
neighbor 10.34.1.3 activate
R1 advertises the 10.1.1.0/24 route to R2 as a normal iBGP advertisement.
R2 receives and advertises the 10.1.1.0/24 route using the route reflector rule 2 as just explained to R3 (a non-route reflector client) (this is why above gap [normal ibgp peering] can be made)
R3 receives and advertises the 10.1.1.0/24 route using the route reflector rule 1 as explained to R4 (a route reflector client).
- Rule 1: If an RR receives an NLRI from a non-RR client, the RR advertises the NLRI to an RR client. It does not advertise the NLRI to a non-RR client.
- Rule 2: If an RR receives an NLRI from an RR client, it advertises the NLRI to RR clients and non-RR clients.
- Rule 3: If an RR receives a route from an eBGP peer, it advertises the route to RR clients and non-RR clients.
See how iBGP between R2 and R3 is non client s
R1# show bgp ipv4 unicast | i Network|10.1.1
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 iR2# show bgp ipv4 unicast | i Network|10.1.1
Network Next Hop Metric LocPrf Weight Path
*>i 10.1.1.0/24 10.12.1.1 0 100 0 iR3# show bgp ipv4 unicast | i Network|10.1.1
Network Next Hop Metric LocPrf Weight Path
*>i 10.1.1.0/24 10.12.1.1 0 100 0 iR4# show bgp ipv4 unicast | i Network|10.1.1
Network Next Hop Metric LocPrf Weight Path
*>i 10.1.1.0/24 10.12.1.1 0 100 0 iNotice the i immediately after the best-path indicator (>) on R2, R3, and R4. This indicates that the prefix is learned through iBGP.
Important notes on RR
Route reflector can be inband or in path or it can be outband or out of data path
With Route Reflector in our iBGP network we dont need to do full mesh iBGP instead we only do iBGP with Route Reflector only
Route Reflectors choose best path based on their perspective or exit point and not perspective of the client this can result in a situation where certain exit point in the network for a prefix is optimal for RR but not optimal for clients
When ibgp routers have multiple paths to compare then one ibgp router can say path A is better and another ibgp router can say that path B is best (based on IGP cost) but when RR is used then RR decides one best path for a prefix and then pushes that to all the clients and now all clients have one best path for a prefix regardless of IGP cost to the next hop
RR only advertise one path for a prefix to the clients and do not advertise any other path to clients
The fix for this is BGP Add Path
BGP Add Path
In standard BGP, a router advertises only one best path per prefix to its neighbors. Because of best path good alternative routes exist but are not advertised
Similarly RRs only advertise their single best path, reducing path diversity.
BGP Add-Path is an extension to BGP that allows a router to advertise multiple paths for the same prefix to a neighbor and this is how router can switch to second path faster.
BGP add path is useful for Datacenters and Large ISP, also networks that use route reflectors
But remember that add path is a capability and is exchanged in open message and needs to be supported and sent by peer
BGP routing table entry for 10.10.10.0/24
Paths: (2 available, best #1)
Advertised to update-groups:
1
Path 1:
Received Path ID 1 <<< ! Received Path ID confirms ADD-PATH
65001 65002
192.0.2.1 from 192.0.2.1 (192.0.2.1)
Origin IGP, localpref 100, valid, external, best
Path 2:
Received Path ID 2 <<< ! Received Path ID confirms ADD-PATH
65003 65002
192.0.2.1 from 192.0.2.1 (192.0.2.1)
Origin IGP, localpref 100, valid, external
Why is BGP Add Path needed when multipath is available?
Multipath makes router use multiple paths, while Additional paths from add path are kept as backup for faster failover
For multipath to work the routes must be equal including AS numbers and AS Path hops must be same and for ibgp routes must be equal including AS numbers and AS Path hops must be same + also the IGP metric to next hop too
Loop Prevention in Route Reflectors
Removing the full mesh requirement in an iBGP topology using route-reflector introduces the potential for routing loops. When RFC 1966 was drafted, two other BGP route reflector–specific attributes were added to prevent loops:
Originator: This optional non-transitive BGP attribute is created by the first route reflector and sets the value to the RID of the router that injected/advertised the prefix into the iBGP network. If Originator is already populated on a route, it should not be overwritten. If a router receives a route with its RID in the Originator attribute, the route is discarded.
Cluster List: This optional non-transitive BGP attribute is updated by the route reflector. This attribute is appended (hence the list , not overwritten) by the route reflector with its cluster ID. By default, this is the BGP identifier. If a route reflector receives a route with its cluster ID in the Cluster List attribute, the route is discarded.
R4# show bgp ipv4 unicast 10.1.1.0/24
! Output omitted for brevity
Paths: (1 available, best #1, table default)
Refresh Epoch 1
Local
10.12.1.1 from 10.34.1.3 (192.168.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 192.168.1.1, Cluster list: 192.168.3.3, 192.168.2.2Confederations
BGP confederations is also an alternative solution to the iBGP full mesh scalability issues
Sub-ASs known as member ASs
Larger AS known as an AS confederation
Member ASs normally use ASNs from the private ASN range (64,512 to 65,534)
eBGP peers peer using confederation AS
Notice that R3 provides route reflection in member AS 65100.
R1
router bgp 100
neighbor 10.12.1.2 remote-as 200R2
router bgp 65100 <<< local bubble
bgp confederation identifier 200 <<< larger bubble
bgp confederation peers 65200 <<< other bubbles we peer with
neighbor 10.12.1.1 remote-as 100 <<< normal peering
neighbor 10.23.1.3 remote-as 65100 <<< normal peering
neighbor 10.25.1.5 remote-as 65200 <<< normal peeringR3
router bgp 65100
bgp confederation identifier 200
neighbor 10.23.1.2 remote-as 65100
neighbor 10.23.1.2 route-reflector-client
neighbor 10.34.1.4 remote-as 65100
neighbor 10.34.1.4 route-reflector-clientR4
router bgp 65100
bgp confederation identifier 200
bgp confederation peers 65200
neighbor 10.34.1.3 remote-as 65100
neighbor 10.46.1.6 remote-as 65200R5
router bgp 65200
bgp confederation identifier 200
bgp confederation peers 65100
neighbor 10.25.1.2 remote-as 65100
neighbor 10.56.1.6 remote-as 65200R6
router bgp 65200
bgp confederation identifier 200
bgp confederation peers 65100
neighbor 10.46.1.4 remote-as 65100
neighbor 10.56.1.5 remote-as 65200
neighbor 10.67.1.7 remote-as 300R7
router bgp 300
neighbor 10.67.1.6 remote-as 200The AS_Path attribute contains a subfield called AS_CONFED_SEQUENCE.
AS_CONFED_SEQUENCE is confederation’s AS PATH but displayed in parentheses before any external ASNs in AS_Path.
As the route passes from member AS to member AS, AS_CONFED_SEQUENCE is appended to contain the member AS ASNs.
The AS_CONFED_SEQUENCE attribute is only used to prevent loops but is not used (counted) when choosing the shortest AS_Path.
Route reflectors can be used within the member AS as in normal iBGP peerings.
The BGP MED attribute is transitive to all other member ASs and Within the confederation, MED is propagated between member sub-ASes but MED is NOT advertised outside the confederation to external ASes. When routes leave the confederation and are advertised to a true external AS: The MED is stripped (unless explicitly re-set by policy).
The LOCAL_PREF attribute is transitive to all other member ASs just like iBGP
The next-hop address for external confederation routes does not change as the route is exchanged between member ASs
AS_CONFED_SEQUENCE is removed from AS_Path when the route is advertised outside the confederation.
AS 100 is not aware that AS 200 is a confederation
R1-AS100# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 10.7.7.0/24 10.12.1.2 0 200 300 i
* 10.12.1.0/24 10.12.1.2 0 0 200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 0 0 200 ?
*> 10.25.1.0/24 10.12.1.2 0 0 200 ?
*> 10.46.1.0/24 10.12.1.2 0 200 ?
*> 10.56.1.0/24 10.12.1.2 0 200 ?
*> 10.67.1.0/24 10.12.1.2 0 200 ?
*> 10.78.1.0/24 10.12.1.2 0 200 300 ?
R2’s BGP table which is in member AS 65100, see that next hop IP address for 10.7.7.0/24 was not changed (advertised by R7) even though it passed different member AS
AS_CONFED_SEQUENCE in parentheses indicates that it passed through sub AS 65200
R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.12.1.1 111 0 100 ?
*> 10.7.7.0/24 10.67.1.7 0 100 0 (65200) 300 i
*> 10.12.1.0/24 0.0.0.0 0 32768 ?
* 10.12.1.1 111 0 100 ?
*> 10.23.1.0/24 0.0.0.0 0 32768 ?
* 10.25.1.0/24 10.25.1.5 0 100 0 (65200) ?
*> 0.0.0.0 0 32768 ?
*> 10.46.1.0/24 10.56.1.6 0 100 0 (65200) ?
*> 10.56.1.0/24 10.25.1.5 0 100 0 (65200) ?
*> 10.67.1.0/24 10.56.1.6 0 100 0 (65200) ?
*> 10.78.1.0/24 10.67.1.7 0 100 0 (65200) 300 ?
Processed 9 prefixes, 11 pathsNotice that the path information includes the attribute confed-internal or confed-external, based on whether the route was received within the same member AS or a different one.
R4# show bgp ipv4 unicast 10.7.7.0/24
! Output omitted for brevity
BGP routing table entry for 10.7.7.0/24, version 504
Paths: (2 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65200) 300
10.67.1.7 from 10.34.1.3 (192.168.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Originator: 192.168.2.2, Cluster list: 192.168.3.3
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
(65200) 300
10.67.1.7 from 10.46.1.6 (192.168.6.6)
Origin IGP, metric 0, localpref 100, valid, confed-external
rx pathid: 0, tx pathid: 0Multiprotocol BGP for IPv6
Multiprotocol BGP (MP-BGP) enables BGP to carry NLRI for different protocols
such as IPv6, MPLS Layer 3 with VRFs info
New BGPv4 optional and nontransitive attributes:
-Multiprotocol reachable NLRI: Describes IPv6 route information
-Multiprotocol unreachable NLRI: Withdraws the IPv6 route from service
These attributes are optional and nontransitive, so if an older router does not understand the attributes, the information can just be ignored as there are a lot of old routing equipment in internet
MP-BGP for IPv6 continues to use the same well-known TCP port 179
IPv4 unicast: AFI:1, SAFI:1
IPv6 unicast: AFI:2, SAFI:1
Unique global unicast addressing is the recommended method for BGP peering to avoid operational complexity. BGP peering using the link-local address may introduce risk if the address is not manually assigned to an interface
R1 advertises all its networks through redistribution
R2 and R3 use the network statement to advertise all their connected networks.
R1
router bgp 65100
bgp router-id 192.168.1.1
no bgp default ipv4-unicast
neighbor 2001:DB8:0:12::2 remote-as 65200
!
address-family ipv6
neighbor 2001:DB8:0:12::2 activate
redistribute connectedR2
router bgp 65200
bgp router-id 192.168.2.2
no bgp default ipv4-unicast
neighbor 2001:DB8:0:12::1 remote-as 65100
neighbor 2001:DB8:0:23::3 remote-as 65300
!
address-family ipv6
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:23::3 activate
network 2001:DB8::2/128
network 2001:DB8:0:12::/64
network 2001:DB8:0:23::/64R3
router bgp 65300
bgp router-id 192.168.3.3
no bgp default ipv4-unicast
neighbor 2001:DB8:0:23::2 remote-as 65200
!
address-family ipv6
neighbor 2001:DB8:0:23::2 activate
network 2001:DB8::3/128
network 2001:DB8:0:3::/64
network 2001:DB8:0:23::/64IPv4 unicast routing capability is advertised by default in IOS XE
for pure IPv6 environment shut down the bgp on IPv4 neighbor or globally within the BGP process with the command no bgp default ipv4-unicast
show bgp ipv6 unicast neighbors ip-address [detail] displays detailed information about whether the IPv6 capabilities were negotiated successfully.
R1# show bgp ipv6 unicast neighbors 2001:DB8:0:12::2
! Output omitted for brevity
BGP neighbor is 2001:DB8:0:12::2, remote AS 65200, external link
BGP version 4, remote router ID 192.168.2.2
BGP state = Established, up for 00:28:25
Last read 00:00:54, last write 00:00:34, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv6 Unicast: advertised and received <<<
Enhanced Refresh Capability: advertised and received
..
For address family: IPv6 Unicast
Session: 2001:DB8:0:12::2
BGP table version 13, neighbor version 13/0
Output queue size : 0
Index 1, Advertise bit 0
1 update-group member
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 3 5 (Consumes 520 bytes)
Prefixes Total: 6 10R2# show bgp ipv6 unicast summary
BGP router identifier 192.168.2.2, local AS number 65200
BGP table version is 19, main routing table version 19
7 network entries using 1176 bytes of memory
8 path entries using 832 bytes of memory
3/3 BGP path/bestpath attribute entries using 456 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2512 total bytes of memory
BGP activity 7/0 prefixes, 8/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:0:12::1 4 65100 35 37 19 0 0 00:25:08 3
2001:DB8:0:23::3 4 65300 32 37 19 0 0 00:25:11 3Notice that some of the prefixes include the unspecified address as the next hop. The unspecified address indicates that the local router is generating the prefix for the BGP table
The weight value 32,768 also indicates that the prefix is locally originated by the router.
This is to force select this as always the best path since BGP best path algorithm has highest weight as top criteria
R1# show bgp ipv6 unicast
BGP table version is 13, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, – - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: – - IGP, – - EGP, – - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::1/128 :: 0 32768 ?
*> 2001:DB8::2/128 2001:DB8:0:12::2 0 0 65200 i
*> 2001:DB8::3/128 2001:DB8:0:12::2 0 65200 65300 i
*> 2001:DB8:0:1::/64 :: 0 32768 ?
*> 2001:DB8:0:3::/64 2001:DB8:0:12::2 0 65200 65300 i
* 2001:DB8:0:12::/64 2001:DB8:0:12::2 0 0 65200 i
*> :: 0 32768 ?
*> 2001:DB8:0:23::/64 2001:DB8:0:12::2 0 65200 iR2# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::1/128 2001:DB8:0:12::1 0 0 65100 ?
*> 2001:DB8::2/128 :: 0 32768 i
*> 2001:DB8::3/128 2001:DB8:0:23::3 0 0 65300 i
*> 2001:DB8:0:1::/64 2001:DB8:0:12::1 0 0 65100 ?
*> 2001:DB8:0:3::/64 2001:DB8:0:23::3 0 0 65300 i
*> 2001:DB8:0:12::/64 :: 0 32768 i
* 2001:DB8:0:12::1 0 0 65100 ?
*> 2001:DB8:0:23::/64 :: 0 32768 i
2001:DB8:0:23::3 0 0 65300 iR3# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::1/128 2001:DB8:0:23::2 0 65200 65100 ?
*> 2001:DB8::2/128 2001:DB8:0:23::2 0 0 65200 i
*> 2001:DB8::3/128 :: 0 32768 i
*> 2001:DB8:0:1::/64 2001:DB8:0:23::2 0 65200 65100 ?
*> 2001:DB8:0:3::/64 :: 0 32768 i
*> 2001:DB8:0:12::/64 2001:DB8:0:23::2 0 0 65200 i
*> 2001:DB8:0:23::/64 :: 0 32768 i
*> 2001:DB8:0:23::2 :: 0 32768 i
* 2001:DB8:0:23::2 0 0 65200 iR3# show bgp ipv6 unicast 2001:DB8::1/128
BGP routing table entry for 2001:DB8::1/128, version 9
Paths: (1 available, best #1, table default)
Not advertised to any peer <<<
Refresh Epoch 2
65200 65100
2001:DB8:0:23::2 (FE80::2) from 2001:DB8:0:23::2 (192.168.2.2)
Origin incomplete, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0Notice that the next-hop address is the link-local address for the next-hop forwarding address, which is resolved through a recursive lookup.
R2# show ipv6 route bgp
IPv6 Routing Table - default - 10 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
B 2001:DB8::1/128 [20/0]
via FE80::1, GigabitEthernet0/0
B 2001:DB8::3/128 [20/0]
via FE80::3, GigabitEthernet0/1
B 2001:DB8:0:1::/64 [20/0]
via FE80::1, GigabitEthernet0/0
B 2001:DB8:0:3::/64 [20/0]
via FE80::3, GigabitEthernet0/1IPv6 over IPv4
BGP can exchange routes using either an IPv4 or IPv6 TCP session
In a typical deployment, IPv4 routes are exchanged using a dedicated IPv4 session, and IPv6 routes are exchanged with a dedicated IPv6 session
However, it is possible to share IPv6 routes over an IPv4 TCP session or IPv4 routes over an IPv6 TCP session
it is also possible to share IPv4 and IPv6 using a single BGP session.
R1
router bgp 65100
bgp router-id 192.168.1.1
no bgp default ipv4-unicast
neighbor 10.12.1.2 remote-as 65200
!
address-family ipv6 unicast
redistribute connected
neighbor 10.12.1.2 activateR2
router bgp 65200
bgp router-id 192.168.2.2
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65300
!
address-family ipv6 unicast
network 2001:DB8::2/128
network 2001:DB8:0:12::/64
aggregate-address 2001:DB8::/62 summary-only
neighbor 10.12.1.1 activate <<< ipv4 neighbor inside IPv6 address family
neighbor 10.23.1.3 activate <<< ipv4 neighbor inside IPv6 address familyR3
router bgp 65300
bgp router-id 192.168.3.3
no bgp default ipv4-unicast
neighbor 10.23.1.2 remote-as 65200
!
address-family ipv6 unicast
network 2001:DB8::3/128
network 2001:DB8:0:3::/64
network 2001:DB8:0:23::/64
neighbor 10.23.1.2 activateR1# show bgp ipv6 unicast summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.12.1.2 4 65200 115 116 11 0 0 01:40:14 2R2# show bgp ipv6 unicast summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.12.1.1 4 65100 114 114 8 0 0 01:39:17 3
10.23.1.3 4 65300 113 115 8 0 0 01:39:16 3R3# show bgp ipv6 unicast summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.23.1.2 4 65200 114 112 7 0 0 01:38:49 2The IPv6 routes advertised over an IPv4 BGP session are assigned an IPv4-mapped IPv6 address in the format (::FFFF:xx.xx.xx.xx) for the next hop, where xx.xx.xx.xx is the IPv4 address of the BGP peering. This is not a valid forwarding address, so the IPv6 route does not populate the RIB.
R1# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 2001:DB8::/62 ::FFFF:10.12.1.2 0 0 65200 i
*> 2001:DB8::1/128 :: 0 32768 ?
*> 2001:DB8:0:1::/64 :: 0 32768 ?
* 2001:DB8:0:12::/64 ::FFFF:10.12.1.2 0 0 65200 i
*> :: 0 32768 ?R2# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/62 :: 32768 i
S 2001:DB8::1/128 ::FFFF:10.12.1.1 0 0 65100 ?
s> 2001:DB8::2/128 :: 0 32768 i
s 2001:DB8::3/128 ::FFFF:10.23.1.3 0 0 65300 i
s 2001:DB8:0:1::/64 ::FFFF:10.12.1.1 0 0 65100 ?
s 2001:DB8:0:3::/64 ::FFFF:10.23.1.3 0 0 65300 i
* 2001:DB8:0:12::/64 ::FFFF:10.12.1.1 0 0 65100 ?
*> :: 0 32768 i
* 2001:DB8:0:23::/64 ::FFFF:10.23.1.3 0 0 65300 iR3# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 2001:DB8::/62 ::FFFF:10.23.1.2 0 0 65200 i
*> 2001:DB8::3/128 :: 0 32768 i
*> 2001:DB8:0:3::/64 :: 0 32768 i
* 2001:DB8:0:12::/64 ::FFFF:10.23.1.2 0 0 65200 i
*> 2001:DB8:0:23::/64 :: 0 32768 iA quick connectivity test between R1 and R3. The output confirms that connectivity cannot be maintained.
R1# ping 2001:DB8:0:3::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:3::3, timeout is 2 seconds:
% No valid route for destination
Success rate is 0 percent (0/1)R1# traceroute 2001:DB8:0:3::3
Type escape sequence to abort.
Tracing the route to 2001:DB8:0:3::3
1 * * *
2 * * *
3 * * *
..To correct the problem, the BGP route map needs to manually set the IPv6 next hop.
R1
route-map FromR1R2Link permit 10
set ipv6 next-hop 2001:DB8:0:12::1
!
router bgp 65100
address-family ipv6 unicast
neighbor 10.12.1.2 route-map FromR1R2LINK outR2
route-map FromR2R1LINK permit 10
set ipv6 next-hop 2001:DB8:0:12::2
route-map FromR2R3LINK permit 10
set ipv6 next-hop 2001:DB8:0:23::2
!
router bgp 65200
address-family ipv6 unicast
neighbor 10.12.1.1 route-map FromR2R1LINK out
neighbor 10.23.1.3 route-map FromR2R3LINK outR3
route-map FromR3R2Link permit 10
set ipv6 next-hop 2001:DB8:0:23::3
!
router bgp 65300
address-family ipv6 unicast
neighbor 10.23.1.2 route-map FromR3R2Link outThe next-hop IP address is valid, and the route can now be installed into the RIB.
R1# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/62 2001:DB8:0:12::2 0 0 65200 i
*> 2001:DB8::1/128 :: 0 32768 ?
*> 2001:DB8:0:1::/64 :: 0 32768 ?
*> 2001:DB8:0:12::/64 :: 0 32768 ?
* 2001:DB8:0:12::2 0 0 65200 iR2# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/62 :: 32768 i
s> 2001:DB8::1/128 2001:DB8:0:12::1 0 0 65100 ?
s> 2001:DB8::2/128 :: 0 32768 i
s> 2001:DB8::3/128 2001:DB8:0:23::3 0 0 65300 i
s> 2001:DB8:0:1::/64 2001:DB8:0:12::1 0 0 65100 ?
s> 2001:DB8:0:3::/64 2001:DB8:0:23::3 0 0 65300 i
*> 2001:DB8:0:12::/64 :: 0 32768 i
r> 2001:DB8:0:23::/64 2001:DB8:0:23::3 0 0 65300 iR3# show bgp ipv6 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/62 2001:DB8:0:23::2
0 0 65200 i
*> 2001:DB8::3/128 :: 0 32768 i
*> 2001:DB8:0:3::/64 :: 0 32768 i
*> 2001:DB8:0:12::/64 2001:DB8:0:23::2 0 0 65200 i
*> 2001:DB8:0:23::/64 :: 0 32768 iSummarization
Summarizing prefixes conserves router resources and accelerates best-path calculation by reducing the size of the table.
Summarization, also known as route aggregation, provides the benefit of stability by hiding route flaps from downstream routers, thereby reducing routing churn
While most service providers do not accept prefixes larger than /24 for IPv4 (/25 through /32), the Internet, at the time of this writing, still has more than 940,000 routes and continues to grow. A router has to receive first and then summaries it towards it neighbors
Dynamic BGP summarization consists of the configuration of an aggregate network prefix. When viable component routes that match the aggregate network prefix enter the BGP table, the aggregate prefix is created. The originating router creates a discard route with next hop to Null0 for the aggregated prefix for loop prevention.
Dynamic route summarization is accomplished with the BGP address family configuration command aggregate-address network subnet-mask [summary-only] [as-set].
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 0 0 65200 ?
*> 172.16.1.0/24 0.0.0.0 0 32768 ?
*> 172.16.2.0/24 0.0.0.0 0 32768 ?
*> 172.16.3.0/24 0.0.0.0 0 32768 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 0 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 0 65200 65300 ?R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 ?
*> 0.0.0.0 0 32768 ?
* 10.23.1.0/24 10.23.1.3 0 0 65300 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.1.0/24 10.12.1.1 0 0 65100 ?
*> 172.16.2.0/24 10.12.1.1 0 0 65100 ?
*> 172.16.3.0/24 10.12.1.1 0 0 65100 ?
*> 192.168.1.1/32 10.12.1.1 0 0 65100 ?
*> 192.168.2.2/32 0.0.0.0 0 32768 ?
*> 192.168.3.3/32 10.23.1.3 0 0 65300 ?R3# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 10.23.1.2 0 0 65200 ?
* 10.23.1.0/24 10.23.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.1.0/24 10.23.1.2 0 65200 65100 ?
*> 172.16.2.0/24 10.23.1.2 0 65200 65100 ?
*> 172.16.3.0/24 10.23.1.2 0 65200 65100 ?
*> 192.168.1.1/32 10.23.1.2 0 65200 65100 ?
*> 192.168.2.2/32 10.23.1.2 0 0 65200 ?
*> 192.168.3.3/32 0.0.0.0 0 32768 ?R1 aggregates all the stub networks (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) into a 172.16.0.0/20 summary route
R2 aggregates all the router’s loopback addresses into a 192.168.0.0/16 summary route
R1# show running-config | section router bgp
router bgp 65100
bgp log-neighbor-changes
aggregate-address 172.16.0.0 255.255.240.0
redistribute connected
neighbor 10.12.1.2 remote-as 65200R2# show running-config | section router bgp
router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0
redistribute connected
neighbor 10.12.1.1 activate
neighbor 10.23.1.3 activate
exit-address-family
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 0 0 65200 ?
*> 172.16.0.0/20 0.0.0.0 32768 i >>> R1 will also install
*> 172.16.1.0/24 0.0.0.0 0 32768 ?
*> 172.16.2.0/24 0.0.0.0 0 32768 ?
*> 172.16.3.0/24 0.0.0.0 0 32768 ?
*> 192.168.0.0/16 10.12.1.2 0 0 65200 i >>> summary received with AS of only 65200 loosing all previous AS PATH info
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 0 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 0 65200 65300 ?R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 ?
*> 0.0.0.0 0 32768 ?
* 10.23.1.0/24 10.23.1.3 0 0 65300 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.12.1.1 0 0 65100 i
*> 172.16.1.0/24 10.12.1.1 0 0 65100 ?
*> 172.16.2.0/24 10.12.1.1 0 0 65100 ?
*> 172.16.3.0/24 10.12.1.1 0 0 65100 ?
*> 192.168.0.0/16 0.0.0.0 32768 i
*> 192.168.1.1/32 10.12.1.1 0 0 65100 ?
*> 192.168.2.2/32 0.0.0.0 0 32768 ?
*> 192.168.3.3/32 10.23.1.3 0 0 65300 ?R3# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 10.23.1.2 0 0 65200 ?
* 10.23.1.0/24 10.23.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.23.1.2 <<< 0 65200 65100 i
*> 172.16.1.0/24 10.23.1.2 0 65200 65100 ?
*> 172.16.2.0/24 10.23.1.2 0 65200 65100 ?
*> 172.16.3.0/24 10.23.1.2 0 65200 65100 ?
*> 192.168.0.0/16 10.23.1.2 <<< 0 0 65200 i
*> 192.168.1.1/32 10.23.1.2 0 65200 65100 ?
*> 192.168.2.2/32 10.23.1.2 0 0 65200 ?
*> 192.168.3.3/32 0.0.0.0 0 32768 ?Notice that the 172.16.0.0/20 and 192.168.0.0/16 network prefixes are visible, but the smaller component network prefixes still exist on all the routers. The aggregate-address command advertises the aggregated network prefix in addition to the original component network prefixes. The optional summary-only keyword suppresses the component network prefixes in the summarized network prefix range.
Configuration with the summary-only keyword.
R1# show running-config | section router bgp
router bgp 65100
bgp log-neighbor-changes
aggregate-address 172.16.0.0 255.255.240.0 summary-only
redistribute connected
neighbor 10.12.1.2 remote-as 65200R2# show running-config | section router bgp
router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 summary-only
redistribute connected
neighbor 10.12.1.1 activate
neighbor 10.23.1.3 activate
exit-address-familyR3# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 10.23.1.2 0 0 65200 ?
* 10.23.1.0/24 10.23.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.23.1.2 0 65200 65100 i
*> 192.168.0.0/16 10.23.1.2 0 0 65200 i
*> 192.168.3.3/32 0.0.0.0 0 32768 ?R2# show bgp ipv4 unicast
BGP table version is 10, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 ?
*> 0.0.0.0 0 32768 ?
* 10.23.1.0/24 10.23.1.3 0 0 65300 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.12.1.1 0 0 65100 i
*> 192.168.0.0/16 0.0.0.0 32768 i
s> 192.168.1.1/32 10.12.1.1 0 0 65100 ? >>> suppressed routes
s> 192.168.2.2/32 0.0.0.0 0 32768 ? >>> suppressed routes
s> 192.168.3.3/32 10.23.1.3 0 0 65300 ? >>> suppressed routes
! all component routes of summary route are suppressed as shown above due to summary-only keyworda summary discard route is installed to Null0 as a loop-prevention mechanism, this null0 route is generated on summarizing router only
R2# show ip route bgp | begin Gateway
Gateway of last resort is not set
172.16.0.0/20 is subnetted, 1 subnets
B 172.16.0.0 [20/0] via 10.12.1.1, 00:06:18
B 192.168.0.0/16 [200/0], 00:05:37, Null0
192.168.1.0/32 is subnetted, 1 subnets
B 192.168.1.1 [20/0] via 10.12.1.1, 00:02:15
192.168.3.0/32 is subnetted, 1 subnets
B 192.168.3.3 [20/0] via 10.23.1.3, 00:02:15R1 suppressing component routes in Loc-RIB
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 0 0 65200 ?
*> 172.16.0.0/20 0.0.0.0 32768 i
s> 172.16.1.0/24 0.0.0.0 0 32768 ?
s> 172.16.2.0/24 0.0.0.0 0 32768 ?
s> 172.16.3.0/24 0.0.0.0 0 32768 ?
*> 192.168.0.0/16 10.12.1.2 0 0 65200 i
*> 192.168.1.1/32 0.0.0.0 0 32768 ?R1# show ip route bgp | begin Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.23.1.0/24 [20/0] via 10.12.1.2, 00:12:50
172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
B 172.16.0.0/20 [200/0], 00:06:51, Null0
B 192.168.0.0/16 [20/0] via 10.12.1.2, 00:06:10The Atomic Aggregate Attribute
Summarized routes act like new BGP routes with a shorter prefix length.
When a BGP router summarizes a route, it does not advertise the AS_Path information from before the route was summarized.
Also path attributes like multi-exit discriminator (MED), and BGP communities are not included in the new BGP aggregate prefix. The atomic aggregate attribute indicates that a loss of path information has occurred.
R2 can be configured to summarize the 172.16.0.0/20 and 192.168.0.0/16 routes with component route suppression
R2# show running-config | section router bgp
router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 summary-only
aggregate-address 172.16.0.0 255.255.240.0 summary-only
redistribute connected
neighbor 10.12.1.1 activate
neighbor 10.23.1.3 activateR2 is aggregating and suppressing R1’s component networks (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) into the 172.16.0.0/20 summary route
The component network prefixes maintain an AS_Path of 65100 on R2
with the aggregate 172.16.0.0/20 appears to be locally generated on R2.
From R3’s perspective, R2 does not advertise R1’s stub networks; instead, it is advertising the 172.16.0.0/20 network as its own
The AS_Path for the 172.16.0.0/20 route on R3 is simply AS 65200 and does not include AS 65100
R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 ?
*> 0.0.0.0 0 32768 ?
* 10.23.1.0/24 10.23.1.3 0 0 65300 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 0.0.0.0 32768 i >>> summarized looks like
>>> locally originated route
s> 172.16.1.0/24 10.12.1.1 0 0 65100 ? >>> while these original
s> 172.16.2.0/24 10.12.1.1 0 0 65100 ? >>> component routes
s> 172.16.3.0/24 10.12.1.1 0 0 65100 ? >>> with real AS PATH
>>> are suppressed
*> 192.168.0.0/16 0.0.0.0 32768 i
s> 192.168.1.1/32 10.12.1.1 0 0 65100 ?
s> 192.168.2.2/32 0.0.0.0 0 32768 ?
s> 192.168.3.3/32 10.23.1.3 0 0 65300 ?R3’s BGP entry for the 172.16.0.0/20 prefix
R3# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 10.23.1.2 0 0 65200 ?
* 10.23.1.0/24 10.23.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.23.1.2 0 0 65200 i
*> 192.168.0.0/16 10.23.1.2 0 0 65200 i
*> 192.168.3.3/32 0.0.0.0 0 32768 ?Drilling down into it further we see that routes were summarized by AS 65200 by the router with the router ID (RID) 192.168.2.2
In addition, the atomic aggregate attribute has been set to indicate a loss of path attributes such as AS_Path in this scenario.
R3# show bgp ipv4 unicast 172.16.0.0
BGP routing table entry for 172.16.0.0/20, version 25
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65200, (aggregated by 65200 192.168.2.2)
10.23.1.2 from 10.23.1.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
rx pathid: 0, tx pathid: 0x0Route Aggregation with AS_SET
To keep the component route’s BGP path information, the optional as-set keyword may be used with the aggregate-address command
There are two types of copy actions that take place inside the AS Path of the aggregate route in BGP
- AS_SEQUENCE copy – this is when all component routes have same AS_PATH info and that is copied over as is (without { })
R3# show bgp ipv4 unicast 172.16.0.0
BGP routing table entry for 172.16.0.0/20, version 30
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65200 65100, (aggregated by 65200 192.168.2.2)
10.23.1.2 from 10.23.1.2 (192.168.2.2)
Origin incomplete, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0- AS_SET – this is when multiple component routes have differing AS_PATH, They are displayed inside { } counts as only one AS hop
R2# show bgp ipv4 unicast 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 28
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
{65100,65300}, (aggregated by 65200 192.168.2.2)
0.0.0.0 from 0.0.0.0 (192.168.2.2)
Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, best
rx pathid: 0, tx pathid: 0x0Configuring as-set for differing prefixes
R2# show running-config | section router bgp
router bgp 65200
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.12.1.1 remote-as 65100
neighbor 10.23.1.3 remote-as 65300
!
address-family ipv4
aggregate-address 192.168.0.0 255.255.0.0 as-set summary-only
aggregate-address 172.16.0.0 255.255.240.0 as-set summary-only
redistribute connected
neighbor 10.12.1.1 activate
neighbor 10.23.1.3 activateWe check 172.16.0.0/20 summary route again, now with the BGP path information copied into it . Notice that the AS_Path information now contains AS 65100.
R3# show bgp ipv4 unicast 172.16.0.0
BGP routing table entry for 172.16.0.0/20, version 30
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65200 65100, (aggregated by 65200 192.168.2.2)
10.23.1.2 from 10.23.1.2 (192.168.2.2)
Origin incomplete, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0R3# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 10.23.1.2 0 0 65200 ?
* 10.23.1.0/24 10.23.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 10.23.1.2 0 0 65200 65100 ?
*> 192.168.3.3/32 0.0.0.0 0 32768 ?Did you notice that the 192.168.0.0/16 summary route is no longer present in R3’s BGP table? The reason for this is on R2; R2 is summarizing all the loopback networks from R1 (AS 65100), R2 (AS 65200), and R3 (AS 65300). And now that R2 is copying the BGP AS_Path attributes of all the component network prefixes into the AS_SET information, the AS_Path for the 192.168.0.0/16 summary route contains AS 65300. When the aggregate is advertised to R3, R3 discards that prefix because it sees its own AS_Path in the advertisement and thinks that it is a loop.
R2# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.1 0 0 65100 ?
*> 0.0.0.0 0 32768 ?
* 10.23.1.0/24 10.23.1.3 0 0 65300 ?
*> 0.0.0.0 0 32768 ?
*> 172.16.0.0/20 0.0.0.0 100 32768 65100 ?
s> 172.16.1.0/24 10.12.1.1 0 0 65100 ?
s> 172.16.2.0/24 10.12.1.1 0 0 65100 ?
s> 172.16.3.0/24 10.12.1.1 0 0 65100 ?
*> 192.168.0.0/16 0.0.0.0 100 32768 {65100,65300} ?
s> 192.168.1.1/32 10.12.1.1 0 0 65100 ?
s> 192.168.2.2/32 0.0.0.0 0 32768 ?
s> 192.168.3.3/32 10.23.1.3 0 0 65300 ?R2# show bgp ipv4 unicast 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 28
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
{65100,65300}, (aggregated by 65200 192.168.2.2)
0.0.0.0 from 0.0.0.0 (192.168.2.2)
Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, best
rx pathid: 0, tx pathid: 0x0R1 does not install the 192.168.0.0/16 summary route for the same reason that R3 does not install the 192.168.0.0/16 summary route. R1 thinks that the advertisement is a loop because it detects AS 65100 in AS_Path. You can confirm this by examining R1’s BGP table
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
* 10.12.1.0/24 10.12.1.2 0 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 0 0 65200 ?
*> 172.16.1.0/24 0.0.0.0 0 32768 ?
*> 172.16.2.0/24 0.0.0.0 0 32768 ?
*> 172.16.3.0/24 0.0.0.0 0 32768 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?Solution here would be not to use as-set command
IPv6 Summarization
The same process for summarizing or aggregating IPv4 prefixes occurs with IPv6 prefixes, and the format is identical except that the configuration is placed under the IPv6 address family using the command aggregate-address prefix/prefix-length [summary-only] [as-set]
Summarization of the IPv6 loopback addresses (2001:db8:::1/128, 2001:db8:::2/128, and 2001:db8::3/128) and R1/R3’s stub networks (2001:db8:0:1::/64 and 2001:db8:0:3/64) is fairly simple as they all fall into the base IPv6 summary range 2001:db8:0:0::/64
The fourth hextet, beginning with a decimal value of 1, 2, or 3, would consume only 2 bits; the range could be summarized easily into the 2001:db8:0:0::/62 (or 2001:db8::/62) network range.
R2# show running-config | section router bgprouter bgp 65200
bgp router-id 192.168.2.2
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::1 remote-as 65100
neighbor 2001:DB8:0:23::3 remote-as 65300
!
address-family ipv4
no neighbor 2001:DB8:0:12::1 activate
no neighbor 2001:DB8:0:23::3 activate
!
address-family ipv6
network 2001:DB8::2/128
network 2001:DB8:0:12::/64
network 2001:DB8:0:23::/64
aggregate-address 2001:DB8::/58 summary-only
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:23::3 activateshows the BGP tables on R1 and R3. Notice that all the smaller component routes are summarized and suppressed into the 2001:db8::/58 summary route, as expected.
R3# show bgp ipv6 unicast | b Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/58 2001:DB8:0:23::2 0 0 65200 i
*> 2001:DB8::3/128 :: 0 32768 i
*> 2001:DB8:0:3::/64 :: 0 32768 i
*> 2001:DB8:0:23::/64 :: 0 32768 iR1# show bgp ipv6 unicast | b Network
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::/58 2001:DB8:0:12::2 0 0 65200 i
*> 2001:DB8::1/128 :: 0 32768 ?
*> 2001:DB8:0:1::/64 :: 0 32768 ?
*> 2001:DB8:0:12::/64 :: 0 32768 ?BGP Route Filtering and Manipulation
Controlling what we learn and advertise can give us control and security, simply relying on peer to be able to install any prefix into our routing domain is not a good idea
IOS XE provides four methods of filtering routes inbound or outbound for a specific BGP peer. Each of these methods can be used individually, or they can be used simultaneously with other methods:
There are multiple ways of filtering or allowing prefixes from BGP neighbors
- Route maps
- Filter List
- AS_Path ACL filtering
- Prefix List or
- Distribute List
A BGP neighbor cannot use a distribute list (ACL) and prefix list at the same time in the same direction (inbound or outbound).
If all are applied together on a BGP neighbor, following are the order of operation for both inbound and outbound
RFAP|D
Filtering on below Loc-RIB
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.3.3.0/24 10.12.1.2 33 0 65200 65300 3003 ?
* 10.12.1.0/24 10.12.1.2 22 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 333 0 65200 ?
*> 100.64.2.0/25 10.12.1.2 22 0 65200 ?
*> 100.64.2.192/26 10.12.1.2 22 0 65200 ?
*> 100.64.3.0/25 10.12.1.2 22 0 65200 65300 300 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 0 65200 65300 ?Distribute List Filtering
Distribute lists has the allow or whitelisting effect
Distribute list uses standard or extended ACLs
Remember that extended ACLs for BGP use the source fields to match the network portion and the destination fields to match against the network mask
The first entry allows any network that starts in the 192.168.0.0 to 192.168.255.255 range with a network length of only /32. The second entry allows networks that contain the 100.64.x.0 pattern with prefix length /25 to demonstrate the wildcard abilities of an extended ACL with BGP
R1
ip access-list extended ACL-ALLOW
permit ip 192.168.0.0 0.0.255.255 host 255.255.255.255
permit ip 100.64.0.0 0.0.255.0 host 255.255.255.128
!
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
address-family ipv4
neighbor 10.12.1.2 distribute-list ACL-ALLOW inThe 100.64.2.192/26 network is rejected because the prefix length or mask does not match the second ACL-ALLOW entry while two of the networks in the 100.64.x.0 pattern (100.64.2.0/25 and 100.64.3.0/25) are accepted
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 0.0.0.0 0 32768 ?
*> 100.64.2.0/25 10.12.1.2 22 0 65200 ?
*> 100.64.3.0/25 10.12.1.2 22 0 65200 65300 300 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 0 65200 65300 ?Prefix List Filtering
Prefix list also has the whitelisting effect same as distribute list but instead of ACL uses prefix list
A prefix list called RFC1918 is created to permit only prefixes in the RFC1918 address space.
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip prefix-list RFC1918 seq 10 permit 10.0.0.0/8 le 32
R1(config)# ip prefix-list RFC1918 seq 20 permit 172.16.0.0/12 le 32
R1(config)# ip prefix-list RFC1918 seq 30 permit 192.168.0.0/16 le 32
R1(config)# router bgp 65100
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# neighbor 10.12.1.2 prefix-list RFC1918 inNotice that the 100.64.2.0/25, 100.64.2.192/26, and 100.64.3.0/25 routes are filtered as they do not fall within the prefix list matching criteria.
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.3.3.0/24 10.12.1.2 33 0 65200 65300 3003 ?
* 10.12.1.0/24 10.12.1.2 22 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 333 0 65200 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 0 65200 65300 ?AS_Path Filtering
There may be times when conditionally matching prefixes may be too complicated, and identifying all routes from a specific organization is preferred, in such cases we can use AS PATH ACL to filer out routes using regex against AS PATH PA
| Modifier | Description |
|---|---|
| _ (underscore) | Matches a space |
| ^ (caret) | Indicates the start of the string |
| $ (dollar sign) | Indicates the end of the string |
| [] (brackets) | Matches a single character or nesting within a range |
| – (hyphen) | Indicates a range of numbers in brackets |
| [^] (caret in brackets) | Excludes the characters listed in brackets |
| () (parentheses) | Used for nesting of search patterns |
| | (pipe) | Provides or functionality to the query |
| . (period) | Matches a single character, including a space |
| * (asterisk) | Matches zero or more characters or patterns |
| + (plus sign) | Matches one or more instances of the character or pattern |
| ? (question mark) | Matches one or no instances of the character or pattern |
BGP table can be parsed with regex using the command show bgp afi safi regexp regex-pattern
so we can test locally before applying it to neighbor
R2# show bgp ipv4 unicast
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0/24 172.32.23.3 0 0 300 80 90 21003 2100 i
*> 172.16.4.0/23 172.32.23.3 0 0 300 878 1190 1100 1010 i
*> 172.16.16.0/22 172.32.23.3 0 0 300 779 21234 45 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i
*> 192.168.0.0/16 172.16.12.1 0 0 100 80 90 21003 2100 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 1100 1010 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 45 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 iAS_Path for the 172.16.129.0/24 route includes AS 300 twice non-consecutively for a specific purpose. This would not be seen in real life because it indicates a routing loop.
_ (Underscore) – Matches a space – AS anywhere regardless of AS position as origin or transit or last AS
Display prefixes coming via AS 100 (regardless of AS 100 position as last or transit or origin AS)
R2# show bgp ipv4 unicast regex 100
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0/24 172.32.23.3 0 0 300 80 90 21003 2100 i
*> 172.16.4.0/23 172.32.23.3 0 0 300 878 1190 1100 1010 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i
*> 192.168.0.0/16 172.16.12.1 0 0 100 80 90 21003 2100 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 1100 1010 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 45 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 iabove did not work so lets try again, The regex query includes the following unwanted ASN: 10010.
R2# show bgp ipv4 unicast regexp _100
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i <<<
*> 192.168.0.0/16 172.16.12.1 0 0 100 80 90 21003 2100 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 1100 1010 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 45 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 iStill did not work, lets try _ before and after _
R2# show bgp ipv4 unicast regexp _100_
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/16 172.16.12.1 0 0 100 80 90 21003 2100 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 1100 1010 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 45 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 iThis one worked because it satisfies the condition of AS 100 existing as either last, or transit, or as origin
^ (Caret) – start of the string – Last AS
Display only prefixes that were advertised from directly connected AS 300 or last AS 300.
R2# show bgp ipv4 unicast regexp ^300_
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0/24 172.32.23.3 0 0 300 80 90 21003 2100 i
*> 172.16.4.0/23 172.32.23.3 0 0 300 878 1190 1100 1010 i
*> 172.16.16.0/22 172.32.23.3 0 0 300 779 21234 45 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i$ (Dollar Sign) – End of the string
Display only prefixes that originated in AS 40
R2# show bgp ipv4 unicast regexp _40$
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 192.168.99.0/24 172.16.12.1 0 100 0 100 145 40 i[ ] (Brackets) – Matches a single character – used for common characters in same place
Display only prefixes with an AS that contains 11 or 14 in it
R2# show bgp ipv4 unicast regexp _1[14]_
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.4.0/23 172.32.23.3 0 0 300 878 14 1100 1010 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 14 40 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 14 1010 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 14 40 i– Hyphen (range matching to reduce the regex size)
Display only prefixes with the last two digits of the AS (40, 50, 60, 70, or 80).
R2# show bgp ipv4 unicast regexp [4-8]0_
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0/24 172.32.23.3 0 0 300 80 90 21003 2100 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i
*> 192.168.0.0/16 172.16.12.1 0 0 100 80 90 21003 2100 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 i[^] (Caret in Brackets) – Excludes the character
Display only prefixes where the second AS from AS 100 or AS 300 does not start with 3, 4, 5, 6, 7, or 8
The first component of the regex query restricts the AS to start with 100 or 300 with the regex query ^[13]00_
and the second component filters out AS starting with 3 through 8 with the regex filter _[^3-8].
R2# show bgp ipv4 unicast regexp ^[13]00_[^3-8]
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 i^[3][0-9]+_[3][0-9]+_[3][0-9]+_
frr.routeviews.org> show bgp ipv4 unicast regexp ^[3][0-9]+_[3][0-9]+_[3][0-9]+_
BGP table version is 264529750, local router ID is 128.223.51.23, vrf id 0
Default local pref 100, local AS 65123
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
V*> 1.6.9.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.11.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.12.0/22 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.13.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.17.0/24 128.223.253.9 0 3582 3701 3356 2914 9583 i
V*= 128.223.253.10 0 3582 3701 3356 2914 9583 i
V*> 1.6.19.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.32.0/22 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.40.0/22 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.48.0/22 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.56.0/22 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.59.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.67.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i
V*> 1.6.69.0/24 128.223.253.9 0 3582 3701 3356 6453 4755 9583 i
V*= 128.223.253.10 0 3582 3701 3356 6453 4755 9583 i( ) and | (Parentheses and Pipe) – for ‘or’ functionality
AS_Path ends with AS 40 or 45 in it
R2# show bgp ipv4 unicast regexp _4(5|0)$
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.0/22 172.32.23.3 0 0 300 779 21234 45 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 40 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 45 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 40 i. (Period) – single character, including a space
Display only prefixes originating from single digit AS
R2# show bgp ipv4 unicast regexp _.$
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.0/22 172.32.23.3 0 0 300 779 21234 4 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 145 4 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 5 i
*> 192.168.16.0/22 172.16.12.1 0 0 100 779 21234 4 i
*> 192.168.99.0/24 172.16.12.1 0 0 100 145 4 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 5 ito match prefixes originating from 2 digit AS
show bgp ipv4 unicast regexp _[0-9][0-9]?$
or
show bgp ipv4 unicast regexp _..$+ (Plus Sign) – one or more instances of the character or pattern.
Display only prefixes that contain “at least one 10” in the AS path but where the pattern 100 should not be used in matching
R2# show bgp ipv4 unicast regexp (10)+[^(100)]
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.4.0/23 172.32.23.3 0 0 300 878 1190 1100 1010 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 1010 40 50 i
*> 192.168.4.0/23 172.16.12.1 0 0 100 878 1190 1100 1010 i
*> 192.168.129.0/24 172.16.12.1 0 0 100 10010 300 1010 40 50 i
(133388)+
frr.routeviews.org> show bgp ipv4 unicast regexp (133388)+
BGP table version is 264877433, local router ID is 128.223.51.23, vrf id 0
Default local pref 100, local AS 65123
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
V*> 1.7.24.0/24 128.223.253.9 0 3582 3701 11164 4637 64049 55836 9583 133388 133388 133388 133388 i
V*= 128.223.253.10 0 3582 3701 11164 4637 64049 55836 9583 133388 133388 133388 133388 i
N*> 162.44.150.0/23 128.223.253.9 0 3582 3701 174 55410 133388 i
N*= 128.223.253.10 0 3582 3701 174 55410 133388 i
N*> 162.44.150.0/24 128.223.253.10 0 3582 3701 11164 4637 64049 55836 55410 133388 i
N*= 128.223.253.9 0 3582 3701 11164 4637 64049 55836 55410 133388 i
N*> 162.44.151.0/24 128.223.253.10 0 3582 3701 11164 4637 64049 55836 55410 133388 i
N*= 128.223.253.9 0 3582 3701 11164 4637 64049 55836 55410 133388 i
N*> 162.44.250.0/24 128.223.253.10 0 3582 3701 11164 4637 64049 55836 55410 133388 i
N*= 128.223.253.9 0 3582 3701 11164 4637 64049 55836 55410 133388 i? (Question Mark) – one or no instances of the character or pattern.
Display only prefixes from the neighboring AS or its directly connected AS (that is, restrict to two ASs away).
You must use the Ctrl+V escape sequence before entering the ?.
R1# show bgp ipv4 unicast regexp ^[0-9]+ ([0-9]+)?$
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.99.0/24 172.32.23.3 0 0 300 40 i
*> 192.168.99.0/24 172.16.12.1 0 100 0 100 40 i* (Asterisk) – zero or more characters or patterns.
Display all prefixes from any AS
decoding .*
. means any character including symbols, alphabets and numbers and * means 0 or more
combining the two means any character 0 or more times which will include content that is null empty (zero) or more (anything)
This may seem like a useless task, but it might be a valid requirement when using AS_Path access lists, which are explained in the following section.
R1# show bgp ipv4 unicast regexp .*
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0/24 172.32.23.3 0 0 300 80 90 21003 2100 i
*> 172.16.4.0/23 172.32.23.3 0 0 300 1080 1090 1100 1110 i
*> 172.16.16.0/22 172.32.23.3 0 0 300 11234 21234 31234 i
*> 172.16.99.0/24 172.32.23.3 0 0 300 40 i
*> 172.16.129.0/24 172.32.23.3 0 0 300 10010 300 30010 30050 i
*> 192.168.0.0/16 172.16.12.1 0 100 0 100 80 90 21003 2100 i
*> 192.168.4.0/23 172.16.12.1 0 100 0 100 1080 1090 1100 1110 i
*> 192.168.16.0/22 172.16.12.1 0 100 0 100 11234 21234 31234 i
*> 192.168.99.0/24 172.16.12.1 0 100 0 100 40 i
*> 192.168.129.0/24 172.16.12.1 0 100 0 100 10010 300 30010 30050 iDifference to remember between + * and ?
+ is 1 or more
while ? and * are more similar to one another
? is 0 or one
* is 0 or more / multiple
AS_Path ACLs
Selecting routes from a BGP neighbor by using AS_Path requires the definition of an AS_Path ACL
The AS_Path ACL processing is performed in a sequential top-down order just like normal ACL,
and the first qualifying match processes against the appropriate permit or deny action.
An implicit deny exists at the end of the AS path ACL.
R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.3.3.0/24 10.23.1.3 33 0 65300 3003 ?
*> 10.12.1.0/24 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 0.0.0.0 0 32768 ?
*> 100.64.2.0/25 0.0.0.0 0 32768 ?
*> 100.64.2.192/26 0.0.0.0 0 32768 ?
*> 100.64.3.0/25 10.23.1.3 3 0 65300 300 ?
*> 192.168.2.2/32 0.0.0.0 0 32768 ?
*> 192.168.3.3/32 10.23.1.3 333 0 65300 ?
Total number of prefixes 8R2 is advertising the routes learned from R3 (AS 65300) to R1, using an AS_Path ACL to restrict the advertisement of only AS 65200 routes is recommended.
R2 using an AS_Path ACL to restrict traffic to only “locally originated” traffic using the regex pattern ^$
R2
ip as-path access-list 1 permit ^$
!
router bgp 65200
address-family ipv4 unicast
neighbor 10.12.1.1 filter-list 1 out
neighbor 10.23.1.3 filter-list 1 outR2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.12.1.0/24 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 0.0.0.0 0 32768 ?
*> 100.64.2.0/25 0.0.0.0 0 32768 ?
*> 100.64.2.192/26 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 0.0.0.0 0 32768 ?
Total number of prefixes 5Route Maps
Route maps provide more functionality than pure filtering; they provide a method to manipulate BGP path attributes, Route maps are applied on a BGP neighbor basis for routes that are advertised or received. A different route map can be used for each direction
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 10.3.3.0/24 10.12.1.2 33 0 65200 65300 3003 ?
* 10.12.1.0/24 10.12.1.2 22 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 333 0 65200 ?
*> 100.64.2.0/25 10.12.1.2 22 0 65200 ?
*> 100.64.2.192/26 10.12.1.2 22 0 65200 ?
*> 100.64.3.0/25 10.12.1.2 22 0 65200 65300 300 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 0 65200 65300 ?Step 1. Deny any routes that are in the 192.168.0.0/16 network by using a prefix list.
Step 2. Match any routes originating from AS 65200 that are within the 100.64.0.0/10 network range and set the BGP local preference to 222.
Step 3. Match any routes originating from AS 65200 that did not match step 2 and set the BGP weight to 65200.
Step 4. Permit all other routes to process.
R1
ip prefix-list FIRST-RFC1918 permit 192.168.0.0/16 le 32
ip as-path access-list 1 permit _65200$
ip prefix-list SECOND-CGNAT permit 100.64.0.0/10 le 32
!
route-map AS65200IN deny 10
description Deny any RFC1918 networks via Prefix List Matching
match ip address prefix-list FIRST-RFC1918
route-map AS65200IN permit 20
description Change local preference for AS65200 originate route in 100.64.x.x/10
match ip address prefix-list SECOND-CGNAT
match as-path 1
set local-preference 222
route-map AS65200IN permit 30
description Change the weight for AS65200 originate routes
match as-path 1
set weight 65200
route-map AS65200IN permit 40
description Permit all other routes un-modified
!
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
address-family ipv4 unicast
neighbor 10.12.1.2 route-map AS65200IN indisplays R1’s BGP routing table, which shows that the following actions occurred:
The 192.168.2.2/32 and 192.168.3.3/32 routes were discarded. The 192.168.1.1/32 route is a locally generated route.
The 100.64.2.0/25 and 100.64.2.192/26 networks had the local preference modified to 222 because they originate from AS 65200 and are within the 100.64.0.0/10 network range.
The 10.12.1.0/24 and 10.23.1.0/24 routes from R2 have been assigned the locally significant BGP attribute weight 65,200.
All other routes were received and not modified.
R1# show bgp ipv4 unicast | b Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 10.3.3.0/24 10.12.1.2 33 0 65200 65300 3003 ?
r> 10.12.1.0/24 10.12.1.2 22 65200 65200 ?
r 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 333 65200 65200 ?
*> 100.64.2.0/25 10.12.1.2 22 222 0 65200 ?
*> 100.64.2.192/26 10.12.1.2 22 222 0 65200 ?
*> 100.64.3.0/25 10.12.1.2 22 0 65200 65300 300 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?clear ip bgp
A hard reset tears down and rebuilds the peering sessions and rebuilds the BGP routing tables
Hard neighborship reset
clear ip bgp *
clear ip bgp neighbor-address
clear ip bgp peer-group group-nameSoft Reconfiguration
A soft reconfiguration uses stored prefix cache without tearing down existing peering sessions at the cost of additional memory for storing the updates, Soft reconfiguration is not on by default and needs to be configured for inbound on neighbors at least, Soft reconfiguration can be configured for inbound or outbound sessions.
neighbor soft-reconfiguration inbound
clear ip bgp 10.100.0.1 soft inRoute Refresh
route refresh capability allows the local router to reset inbound routing tables dynamically by sending route refresh requests given the neighbor not just supports it but also negotiated route refresh capability
clear ip bgp 172.16.10.2 inBGP Communities
BGP communities are optional attributes that let routers attach tags to routes so other routers can apply routing policies (like prefer, filter, or modify routes) without inspecting prefixes in detail.
A BGP community is an optional transitive BGP attribute that can traverse from AS to AS.
A BGP community is a 32-bit number that can be included with a route
A BGP community can be displayed as a full 32-bit number (0 through 4,294,967,295) or as two 16-bit numbers (0 through 65535):(0 through 65535), commonly referred to as new format.
By convention, with private BGP communities, the first 16 bits represent the AS of the community and the second 16 bits represent a pattern defined by the originating AS
Format
- 32-bit value
- Usually written as:
ASN:VALUE(e.g.65000:100)
Well-known standard communities
These have predefined meanings:
no-export→ do not advertise to eBGP peersno-advertise→ do not advertise to any peerinternet→ advertise everywhere
Extended BGP communities:
Format
- 64-bit value
- Structured into sub-fields, not just a single number
- Encoded as Type + Value
Examples (vendor CLI format varies):
rt 65000:100(Route Target)soo 65000:200(Site of Origin)
What they’re used for
Extended communities were introduced to solve the limitations of standard communities, especially for:
- MPLS VPNs
- L3VPN / L2VPN
- Advanced traffic engineering
- EVPN
- Policy precision across large networks
Common types of extended communities
- Route Target (RT) – controls VPN route import/export
- Route Distinguisher-related signaling
- Site of Origin (SoO) – prevents routing loops
- Bandwidth, color, QoS, and traffic engineering attributes
Advantages
Much more expressive
Globally meaningful when standardized
Safer for large multi-AS or service provider networks
Designed for scalable VPN and EVPN environments
Enabling BGP Community Support
IOS XE routers do not advertise BGP communities to peers by default. Communities are enabled on a neighbor-by-neighbor basis
neighbor ip-address send-community [standard | extended | both]
! If a keyword is not specified, standard communities are sent by defaultIOS XE nodes can display communities in new format, and they are easier to read if you use the global configuration command
ip bgp-community new-format! DECIMAL FORMAT
R3# show bgp 192.168.1.1
! Output omitted for brevity
BGP routing table entry for 192.168.1.1/32, version 6
Community: 6553602 6577023! New-Format
R3# show bgp 192.168.1.1
! Output omitted for brevity
BGP routing table entry for 192.168.1.1/32, version 6
Community: 100:2 100:23423Well-Known Communities
RFC 1997 defined a set of global communities (known as well-known communities) that use the community range 4,294,901,760 (0xFFFF0000) to 4,294,967,295 (0xFFFFFFFF).
All routers that are capable of sending/receiving BGP communities must implement well-known communities.
The following are the common well-known communities:
- Internet
- No_Advertise
- No_Export
- Local AS
The No_Advertise BGP Community
For the No_Advertise community (0xFFFFFF02 or 4,294,967,042), routes should not be advertised to any BGP peer. The No_Advertise BGP community can be advertised from an upstream BGP peer or locally with an inbound BGP policy.
In either method, the No_Advertise community is set in the BGP Loc-RIB table that affects outbound route advertisement. The No_Advertise community is set with the command set community no-advertise within a route map
R1 is advertising the 10.1.1.0/24 route to R2.
R2 sets the BGP No_Advertise community on the prefix on an inbound route map associated with R1.
R2 does not advertise the 10.1.1.0/24 route to R3
Notice that the route was “not advertised to any peer” and has the BGP community No_Advertise set.
R2# show bgp 10.1.1.0/24
! Output omitted for brevity
BGP routing table entry for 10.1.1.0/24, version 18
Paths: (1 available, best #1, table default, not advertised to any peer)
Not advertised to any peer
Refresh Epoch 1
100, (received & used)
10.1.12.1 from 10.1.12.1 (192.168.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-advertiseYou can quickly see BGP routes that are set with the No_Advertise community by using the command show bgp afi safi community no-advertise
R2# show bgp ipv4 unicast community no-advertise
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.12.1 0 0 100 iThe No_Export BGP Community
When a route is received with the No_Export community (0xFFFFFF01 or 4,294,967,041), the route is not advertised to any eBGP peer. If the router receiving the No_Export route is a confederation member, the route can be advertised to other sub-ASs in the confederation
The No_Export community is set with the command set community no-export within a route map.
AS 200 is a BGP confederation composed of member AS 65100 and AS 65200
R1 is advertising the 10.1.1.0/24 route to R2, and R2 sets the No_Export community on an inbound route map associated with R1. R2 advertises the prefix to R3, and R3 advertises the prefix to R4. R4 does not advertise the prefix to R5 because it is an eBGP session
Notice that R4 display not advertised to EBGP peer.
R3# show bgp ipv4 unicast 10.1.1.0/24
BGP routing table entry for 10.1.1.0/24, version 6
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
Advertised to update-groups:
3
Refresh Epoch 1
100, (Received from a RR-client), (received & used)
10.1.23.2 from 10.1.23.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Community: no-exportR4# show bgp ipv4 unicast 10.1.1.0/24
! Output omitted for brevity
BGP routing table entry for 10.1.1.0/24, version 4
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
(65100) 100, (received & used)
10.1.23.2 (metric 20) from 10.1.34.3 (192.168.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
Community: no-exportYou can see all the BGP prefixes that contain the No_Export community by using the command show bgp afi safi community no-export
R4# show bgp ipv4 unicast community no-export | b Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.23.2 0 100 0 (65100) 100 iR2# show bgp ipv4 unicast community no-export | b Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.12.1 0 0 100 iThe Local AS (No_Export_SubConfed) BGP Community
With the No_Export_SubConfed community (0xFFFFFF03 or 4,294,967,043), known as the local AS community, a route is not advertised outside the local AS. The local AS community is set with the command set community local-as within a route map.
R2 sets the local AS community on an inbound route map associated with R1. R2 advertises the prefix to R3, but R3 does not advertise the prefix to R4 because the prefix contains the local AS community.
R3# show bgp ipv4 unicast 10.1.1.0/24
BGP routing table entry for 10.1.1.0/24, version 8
Paths: (1 available, best #1, table default, not advertised outside local AS)
Not advertised to any peer
Refresh Epoch 1
100, (Received from a RR-client), (received & used)
10.1.23.2 from 10.1.23.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Community: local-ASYou can see all the BGP prefixes that contain the local AS community by using the command show bgp afi safi community local-as
R3# show bgp ipv4 unicast community local-AS | b Network
Network Next Hop Metric LocPrf Weight Path
*>i 10.1.1.0/24 10.1.23.2 0 100 0 100 iR2# show bgp ipv4 unicast community local-AS | b Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.12.1 0 0 100 iConditionally Matching BGP Communities
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
* 10.12.1.0/24 10.12.1.2 22 0 65200 ?
*> 0.0.0.0 0 32768 ?
*> 10.23.1.0/24 10.12.1.2 333 0 65200 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 0 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 0 65200 65300 ?show bgp afi safi detail and then manually select a route with a specific community. However, if the BGP community is known, you can display all the routes by using the command show bgp afi safi community community, as shown in the following snippet:
R1# show bgp ipv4 unicast community 333:333 | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.23.1.0/24 10.12.1.2 333 0 65200 ?10.23.1.0/24 route and all the BGP path attributes. Notice that two BGP communities (333:333 and 65300:333) are added to the path.
R1# show ip bgp 10.23.1.0/24
BGP routing table entry for 10.23.1.0/24, version 15
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 3
65200
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin incomplete, metric 333, localpref 100, valid, external, best
Community: 333:333 65300:333 <<<
rx pathid: 0, tx pathid: 0x0Conditionally matching requires the creation of a community list that shares a structure similar to that of an ACL
Standard community lists are numbered 1 to 99 and match either well-known communities or a private community number (as-number:16-bit-number)
Expanded community lists are numbered 100 to 500 and use regex patterns.
When multiple communities are on the same ip community list statement, all communities for that statement must exist in that route’s community list. If only one out of many communities is required, you can use multiple ip community list statements.
ip community 1 permit 11:100 11:200BGP community list that matches on the community 333:333
The BGP community list is then used in the first sequence of route map COMMUNITY-CHECK, which denies any routes with that community.
The second route map sequence allows for all other BGP routes and sets the BGP weight (locally significant) to 111. The route map is then applied on routes advertised from R2 toward R1.
R1
ip community-list 100 permit 333:333
!
route-map COMMUNITY-CHECK deny 10
description Block Routes with Community 333:333 in it
match community 100
route-map COMMUNITY-CHECK permit 20
description Allow routes with either community in it
set weight 111
!
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
address-family ipv4 unicast
neighbor 10.12.1.2 route-map COMMUNITY-CHECK in10.23.1.0/24 prefix is discarded, and all the other prefixes learned from AS 65200 have the BGP weight set to 111
R1# show bgp ipv4 unicast | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
* 10.12.1.0/24 10.12.1.2 22 111 65200 ?
*> 0.0.0.0 0 32768 ?
*> 192.168.1.1/32 0.0.0.0 0 32768 ?
*> 192.168.2.2/32 10.12.1.2 22 111 65200 ?
*> 192.168.3.3/32 10.12.1.2 3333 111 65200 65300 ?Setting Private BGP Communities
You set a private BGP community in a route map by using the command set community bgp-community [additive]. By default, when you set a community, any existing communities are overwritten, but you can preserve them by using the optional additive keyword.
10.23.1.0/24 route, which has the 333:333 and 65300:333 BGP communities. The 10.3.3.0/24 route has the 65300:300 community.
R1# show bgp ipv4 unicast 10.23.1.0/24
! Output omitted for brevity
BGP routing table entry for 10.23.1.0/24, version 15
65200
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin incomplete, metric 333, localpref 100, valid, external, best
Community: 333:333 65300:333R1# show bgp ipv4 unicast 10.3.3.0/24
! Output omitted for brevity
BGP routing table entry for 10.3.3.0/24, version 12
65200 65300 3003
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin incomplete, metric 33, localpref 100, valid, external, best
Community: 65300:300When additive keyword is not used, so the previous community values of 333:333 and 65300:333 are overwritten with the 10:23 community.
ip prefix-list PREFIX10.23.1.0 seq 5 permit 10.23.1.0/24
ip prefix-list PREFIX10.3.3.0 seq 5 permit 10.3.3.0/24
!
route-map SET-COMMUNITY permit 10
match ip address prefix-list PREFIX10.23.1.0
set community 10:23
route-map SET-COMMUNITY permit 20
match ip address prefix-list PREFIX10.3.3.0
set community 3:0 3:3 10:10 additive
route-map SET-COMMUNITY permit 30
!
router bgp 65100
address-family ipv4
neighbor 10.12.1.2 route-map SET-COMMUNITY inAfter the route map has been applied and the routes have been refreshed, the path attributes can be examined
As anticipated, the previous BGP communities are removed for the 10.23.1.0/24 route, but they are maintained with the 10.3.3.0/24 route.
R1# show bgp ipv4 unicast 10.23.1.0/24
! Output omitted for brevity
BGP routing table entry for 10.23.1.0/24, version 22
65200
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin incomplete, metric 333, localpref 100, valid, external, best
Community: 10:23R1# show bgp ipv4 unicast 10.3.3.0/24
BGP routing table entry for 10.3.3.0/24, version 20
65200 65300 3003
10.12.1.2 from 10.12.1.2 (192.168.2.2)
Origin incomplete, metric 33, localpref 100, valid, external, best
Community: 3:0 3:3 10:10 65300:300Maximum Prefix
Multiple Internet outages have occurred because routers have received more routes than they can handle. The BGP maximum prefix feature restricts the number of routes that are received from a BGP peer.
Prefix limits are typically set for BGP peers on low-end routers as a safety mechanism to ensure that they do not become overloaded.
You can have routers place prefix restrictions on a BGP neighbor by using the BGP address family configuration command neighbor ip-address maximum-prefix prefix-count [warning-percentage] [restart time] [warning-only].
When a peer advertises more routes than the maximum prefix count, the peer moves the neighbor to the Idle (PfxCt) state in the finite-state machine (FSM)
closes the BGP session, and sends out the appropriate syslog message. The BGP session is not automatically reestablished by default. This behavior prevents a continuous cycle of loading routes, resetting the session, and reloading the routes. If you want to restart the BGP session after a certain amount of time, you can use the optional keyword restart time.
A warning is not generated before the prefix limit is reached. By adding a warning percentage (set to 1 to 100) after the maximum prefix count, you can have a warning message sent when the percentage is exceeded. The command for a maximum of 100 prefixes with a warning threshold of 75 is maximum-prefix 100 75. When the threshold is reached, the router reports the following warning message:
%ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes received from
192.168.1.1 has reached 75, max 100You can change the maximum prefix behavior of closing the BGP session by using the optional keyword warning-only so that a warning message is generated instead.
router bgp 65100
neighbor 10.12.1.2 remote-as 65200
!
address-family ipv4
neighbor 10.12.1.2 activate
neighbor 10.12.1.2 maximum-prefix 7shows that the 10.12.1.2 neighbor has exceeded the maximum prefix threshold and shut down the BGP session.
R1# show bgp ipv4 unicast summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.12.1.2 4 65200 0 0 1 0 0 00:01:14 Idle (PfxCt)R1# show log | include BGP
05:10:04.989: %BGP-5-ADJCHANGE: neighbor 10.12.1.2 Up
05:10:04.990: %BGP-4-MAXPFX: Number of prefixes received from 10.12.1.2 (afi 0)
reaches 6, max 7
05:10:04.990: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.12.1.2
(afi 0): 8 exceeds limit 7
05:10:04.990: %BGP-3-NOTIFICATION: sent to neighbor 10.12.1.2 6/1
(Maximum Number of Prefixes Reached) 7 bytes 00010100 000007
05:10:04.990: %BGP-5-NBR_RESET: Neighbor 10.12.1.2 reset
(Peer over prefix limit)
05:10:04.990: %BGP-5-ADJCHANGE: neighbor 10.12.1.2 Down Peer over prefix limitIOS XE Peer Groups
IOS XE peer groups simplify BGP configuration and reduce system resource use (CPU and memory) by grouping BGP peers together into BGP update groups. BGP update groups enable a router to perform the outbound routing policy processing one time and then replicate the update to all the members (as opposed to performing the outbound routing policy processing for every router).
The routers in a BGP peer group must contain the same outbound routing policy and same bgp connection type iBGP or eBGP
In addition to enhancing router performance, BGP peer groups simplify the BGP configuration
All routers in the peer group are in the same update group and therefore must be of the same session type: internal (iBGP) or external (eBGP).
Members of a peer group can have a unique inbound routing policy.
router bgp 100
no bgp default ipv4-unicast
neighbor AS100 peer-group
neighbor AS100 remote-as 100
neighbor AS100 update-source Loopback0
neighbor 192.168.2.2 peer-group AS100
neighbor 192.168.3.3 peer-group AS100
neighbor 192.168.4.4 peer-group AS100
!
address-family ipv4
neighbor AS100 next-hop-self
neighbor 192.168.2.2 activate
neighbor 192.168.3.3 activate
neighbor 192.168.4.4 activateIOS XE Peer Templates
A restriction for BGP peer groups is that they require all neighbors to have the same outbound routing policy.
BGP peer templates allow for a reusable pattern of settings that can be applied as needed in a hierarchical format through inheritance and nesting of templates.
If a conflict exists between an inherited configuration and the invoking peer template, the invoking template preempts the inherited value
There are two types of BGP peer templates:
- Peer session: This template allows bgp neighbor configuration, template peer-session template-name and then enter any BGP session-related configuration commands.
- Peer policy: This template allows loc-RIB related configuration, template peer-policy template-name and then enter any BGP address family–related configuration commands.
BGP neighbor 10.12.1.2 invokes TEMPLATE-PARENT-POLICY for address family policy settings. TEMPLATE-PARENT-POLICY sets the inbound route map to FILTERROUTES and invokes TEMPLATE-CHILD-POLICY, which sets the maximum prefix limit to 10.
router bgp 100
template peer-policy TEMPLATE-PARENT-POLICY
route-map FILTERROUTES in
inherit peer-policy TEMPLATE-CHILD-POLICY 20
exit-peer-policy
!
template peer-policy TEMPLATE-CHILD-POLICY
maximum-prefix 10
exit-peer-policy
!
bgp log-neighbor-changes
neighbor 10.12.1.2 remote-as 200
!
address-family ipv4
neighbor 10.12.1.2 activate
neighbor 10.12.1.2 inherit peer-policy TEMPLATE-PARENT-POLICYA BGP peer can be associated with either a peer group or a template but not both.
A BGP peer can be attached to either peer group or peer template
BGP Deterministic MED
https://ipwithease.com/understanding-bgp-deterministic-med/
To understand the use of BGP deterministic-MED we must first understand behavior of BGP algorithm when a route is received on a router via multiple paths
As prefixes are being received, BGP algorithm assigns the first valid path as the current best path
This first valid path is then compared with the next path that is received for “same prefix”
1st and 2nd path are compared and out them the one chosen as best is then compared with 3rd path and so on until the end of paths is reached – best paths are compared as they are being received
Because of above behavior we can have an effect where it looks like MED is not being used.
Similar to BGP always compare-MED feature that ensures the MED gets compared when different AS are advertising the same route
BGP Deterministic-med feature ensures the MED gets compared deterministically for a routes advertised from different paths in same AS.
show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 29
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Flag: 0x4842
Advertised to update-groups:
1
300 400
9.9.13.3 from 9.9.13.3
Origin IGP, metric 100, localpref 100, valid, external
200 400
9.9.12.2 from 9.9.12.2
Origin IGP, metric 150, localpref 100, valid, external
300 400
9.9.14.4 from 9.9.14.4
Origin IGP, metric 200, localpref 100, valid, external, best <<<
N
WLLA
OMNI
MAR-CL N
Next hop - Valid
Weight - Higher weight
Local preference - Highest preference
Locally originated - locally originated preferred over learned from neighbors
AS Path - shorter AS Path
Origin - origin codes i over ?
MED - lower MED from same AS <<<
Neighbor type - ebgp over ibgp
IGP metric - lower IGP metric of next hop
Multipath - if configured then BGP will keep both
Age - oldest route that was learned <<<
Router ID - lower RID
CL - shorter Cluster list length
Neighbor address - lower Between the Route from R3 and R2 , R2 is chosen as the best path. This is so because the MED isn’t compared for BGP updates from R2 & R3 as they are part of different AS and as per BGP algorithms working the older route is preferred one which here is from R2 (because if you look at the output everything else is same)
Now comparing routes from R2 with route from R4 again MED isn’t compared as they are both from different AS. R4 being the older route here is preferred over the route from R2 and hence is selected as the best. So we see in this scenario how the MED working of preferring the lower MED updates hasn’t taken effect in this scenario.
To overcome this situation we use BGP deterministic-med
Deterministic-med groups all routes for a prefix from same AS under a same group in BGP table and then compare against each other, Then the best of the group is compared against the next group down
R1(config)#router bgp 100
R1(config-router)#bgp deterministic-medshow ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 29
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Flag: 0x4842
Advertised to update-groups:
1
200 400
9.9.12.2 from 9.9.12.2
Origin IGP, metric 100, localpref 100, valid, external
300 400
9.9.13.3 from 9.9.13.3
Origin IGP, metric 150, localpref 100, valid, external best <<<
300 400
9.9.14.4 from 9.9.14.4
Origin IGP, metric 200, localpref 100, valid, external,Now we see the table has been restructured and the routes with same AS path are grouped together.
Routes from R3 and R4 are compared because they are from same AS 300 and since route from R3 has lower MED it is best out of the group.
Now R3’s route is compared with the only route of other group i.e. from R2 and since both routes are from different AS, MED comparison will be skipped again, the route from R3 is older and it wins as best despite R2 having lower MED, this comparison still takes place because of belonging to same prefix
Dynamic BGP Neighbors
https://ipwithease.com/dynamic-bgp-peering/
we use the concept of BGP peer Group, where we can group the BGP Neighbors who are sharing the same outbound policies but with peer groups alone we need to manually configure 100 Peers and then add to the peer group so we need to combine it with another feature
Configuration step of iBGP Peer Group
router bgp 65001
bgp log-neighbor-changes
neighbor ibgp-peers peer-group
neighbor ibgp-peers remote-as 65001
neighbor 123.1.1.2 peer-group ibgp-peers
neighbor 123.1.1.3 peer-group ibgp-peersConfiguration step of eBGP peer Group
ip route 1.1.1.2 255.255.255.255 123.1.1.2
ip route 1.1.1.3 255.255.255.255 123.1.1.3
router bgp 65001
bgp log-neighbor-changes
neighbor ebgp-peers peer-group
neighbor ebgp-peers ebgp-multihop 2
neighbor ebgp-peers update-source loopback0
neighbor 123.1.1.2 remote-as 65002
neighbor 123.1.1.2 peer-group ebgp-peers
neighbor 123.1.1.3 remote-as 65003
neighbor 123.1.1.3 peer-group ebgp-peersWith the Dynamic BGP peering feature, BGP router dynamically establishes peering with a group of remote neighbors that are configured using a range of IP addresses + BGP peer group.
R1(config-router)# neighbor dynamic-peers peer-groupCreate a global limit of BGP dynamic subnet range neighbors. The value ranges from 1 to 5000.
R1(config-router)# bgp listen limit 100define IP range for this peer-group
R1(config-router)# bgp listen range 172.16.0.0/16 peer-group dynamic-peersDefine the remote-as for the peer group, optionally, define the list of AS numbers that can be accepted to form neighborship with, max limit of alternate-as numbers is 5
R1(config-router)# neighbor dynamic-peers remote-as 65002 alternate-as 65003 65004Activate the peer group under ipv4 address-family, just like we activate a neighbor
R1(config-router)#address-family ipv4
R1(config-router-af)# neighbor dynamic-peers activate.Full configuration
R1
router bgp 65001
bgp log-neighbor-changes
bgp listen range 172.16.0.0/16 peer-group dynamic-peers
neighbor dynamic-peers peer-group
neighbor dynamic-peers remote-as 65002 alternate-as 65003 65004
!
address-family ipv4
neighbor dynamic-peers activate
exit-address-familyR2
router bgp 65002
bgp log-neighbor-changes
!
neighbor 172.16.1.1 remote-as 65001R3
router bgp 65003
bgp log-neighbor-changes
!
neighbor 172.16.2.1 remote-as 65001BGP router identifier 10.10.10.1, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*172.16.1.2 4 65002 4 4 1 0 0 00:00:38 0
*172.16.2.2 4 65003 4 2 1 0 0 00:00:29 0
! Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1
BGP peer group Dynamic-peer listen range group members:
172.16.0.0/16
Total dynamically created neighbors: 2/(100 max), Subnet ranges: 1show tcp brief all
TCB Local Address Foreign Address (state)
A2B61B90 172.16.1.1.179 172.16.1.2.64321 ESTAB
A2B62F48 172.16.2.1.179 172.16.2.2.17764 ESTAB
A2B19B20 0.0.0.0.179 *.* LISTENThe output illustrates that the router is listening on port 179 but with foreign address of *.*
BGP Allowas-in
https://ipwithease.com/allowas-in-configuration-in-bgp-2/
BGP allowas-in feature allows a router to accept BGP routes that contain its own AS number in the AS path
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.23.2 allowas-inBGP local-AS
https://journey2theccie.wordpress.com/2020/06/15/bgp-as-path-manipulations/
The local-AS feature allows a router to fool its neighbor to have a different AS then real AS at “router bgp ” configuration, but only for neighborship, the real AS still appears in AS Path and then the faked AS
R1#sh run | s router bgp
router bgp 65000
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 12.0.0.2 remote-as 2
neighbor 12.0.0.2 local-as 1 <<<R2#sh run | s router bgp
router bgp 2
bgp log-neighbor-changes
network 2.2.2.0 mask 255.255.255.0
neighbor 12.0.0.1 remote-as 1 <<<R2#show bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 12.0.0.1 0 0 1 65000 iAs you can see, both AS numbers are there in the path. They also are there on routes that R1 is learning from R2, this fake AS really acts as another AS inserted in topology:
R1#sh ip bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 12.0.0.2 0 0 1 2 i
There are a couple of ways to change this. First, if we want to stop the alternate ASN from being prepended when receiving routes, we can use no-prepend:
R1(config-router)#neighbor 12.0.0.2 local-as 1 no-prepend
R1#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 2.2.2.0/24 12.0.0.2 0 0 2 i
We can see that the routes learned from R2 no longer are showing 1 in the path. However, if we look at R2….
R2#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 12.0.0.1 0 0 1 65000 i
*> 2.2.2.0/24 0.0.0.0 0 32768 iBoth of our ASNs are in the path. So to stop the alternate ASN from being prepended when sending routes, we can use the following:
R1(config-router)#neighbor 12.0.0.2 local-as 1 no-prepend replace-asNow if we look at R2:
R2#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 12.0.0.1 0 0 1 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
We can see that only 1 is in the path. Using both the no-prepend replace-as keywords allow all routers to see the BGP advertisements as if they were running AS 1 in the BGP process.
There is still one more keyword for this command, and it is the dual-as keyword:
R1(config-router)#neighbor 12.0.0.2 local-as 1 no-prepend replace-as ?
dual-as Accept either real AS or local AS from the ebgp peer
<cr>This allows the remote peer to use either ASN for the BGP session. This feature is useful during migrations.
BGP remove-private-as
https://journey2theccie.wordpress.com/2020/06/15/bgp-as-path-manipulations/
There are situations where a customer with a single ISP may use a private ASN on the internet connection. In these cases, when the ISP forwards the customer’s prefix(s) out it will remove the private ASN in the process.
This is where Cisco router’s use the remove-private-as command. However, there are certain restrictions:
EBGP neighbors only
The private ASNs are removed from outbound updates
This only works if the path has only private ASNs in the AS_PATH. If there is a mix of public and private this will not work, however there is a way to fix this
If the AS_PATH contains the ASN of the EBGP neighbor, it won’t be removed
R1#sh run | s bgp
router bgp 65000
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 12.0.0.2 remote-as 2R2#sh run | s bgp
router bgp 2
bgp log-neighbor-changes
neighbor 12.0.0.1 remote-as 65000
neighbor 24.0.0.4 remote-as 4R4#sh run | s router bgp
router bgp 4
bgp log-neighbor-changes
neighbor 24.0.0.2 remote-as 2If we look at R2 & R4, we can see they have learned the route with the private AS in the path:
R2#show ip bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 12.0.0.1 0 0 65000 i
!
R4#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 24.0.0.2 0 2 65000 iSo let’s enable that command on R2 and see how it shows up on R4:
R2(config-router)#neighbor 24.0.0.4 remove-private-as
!
R4#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 24.0.0.2 0 2 i
That worked easily enough.
So remember what I said about not being able to do it when there are public and private AS numbers in the AS path? Let’s test that by adding a bunch of AS numbers to the path and see if it still works.
R1(config)#route-map PREPEND permit 10 R1(config-route-map)#set as-path prepend 1 10 100 R1(config-route-map)#exit R1(config)#router bgp 65000 R1(config-router)#neighbor 12.0.0.2 route-map PREPEND out
Let’s check the route back on R4:
R4#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 24.0.0.2 0 2 65000 1 10 100 iAs you can see, the private AS is still in the path because there are public AS numbers there and Cisco IOS assumes that the remote-private-as command was a misconfiguration. We can override this with the all keyword:
R2(config-router)#neighbor 24.0.0.4 remove-private-as allThis will remove private AS numbers regardless of what else is in the path. Let’s check R4:
R4#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 24.0.0.2 0 2 1 10 100 iPerfect, now the private AS is gone, but the rest of the ASNs remain.
Removal of AS shortens the path unintentionally so sometimes it is important to keep the ASN entries to equal number, instead of removing them, so instead we can use replace-as with remove-private-as
R2(config-router)#neighbor 24.0.0.4 remove-private-as all replace-as
!
R4#sh bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 24.0.0.2 0 2 2 1 10 100 i
Now we can see our AS (2) in the path instead of the private AS of 65000.
BGP Conditional Advertisement
https://ipwithease.com/bgp-conditional-route-advertisement-using-non-exist-map-advertise-map/
By default BGP router advertises all best path routes from Loc-RIB to all its neighbors.
Using conditional advertisement some prefixes are advertised to one of the providers only if information from the other provider is not present. This will help keep routing symmetric
With the BGP conditional advertisement feature, you can now accomplish these tasks on R2:
- If 1.1.1.1/32 exists in R2’s BGP table, then do not advertise the 2.2.2.2/32 network to R3.
- If 1.1.1.1/32 does not exist in R2’s BGP table, then advertise the 2.2.2.2/32 network to R3.
R1
router bgp 100
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 9.9.12.2 remote-as 200R2
router bgp 200
bgp log-neighbor-changes
network 2.2.2.2 mask 255.255.255.255
neighbor 9.9.12.1 remote-as 100
neighbor 9.9.23.3 remote-as 300
neighbor 9.9.23.3 advertise-map Advertise non-exist-map Non-Exist
!
access-list 10 permit 2.2.2.2
access-list 20 permit 1.1.1.1
!
route-map Non-Exist permit 10
match ip address 20
!
route-map Advertise permit 10
match ip address 10R3
router bgp 300
bgp log-neighbor-changes
neighbor 9.9.23.2 remote-as 200R2#sh ip bgp
BGP table version is 3, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 9.9.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 iR2#sh ip bgp neighbors 9.9.23.3 advertised-routes
BGP table version is 3, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 9.9.12.1 0 0 100 i
Total number of prefixes 1R3#sh ip bgp
BGP table version is 8, local router ID is 9.9.23.3Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 9.9.23.2 0 200 100 i <<<
! Only 1.1.1.1/32 is received and not 2.2.2.2Now we will shut down Lo0 interface on R1 to stop the advertisement of 1.1.1.1 to R2 and hence will see 2.2.2.2 is received on R3 now from R2.
R1(config)#int loop 0
R1(config-if)#shutdownR2#sh ip bgp neighbors 9.9.23.3 advertised-routes
BGP table version is 5, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 0.0.0.0 0 32768 i
Total number of prefixes 1R3#sh ip bgp
BGP table version is 10, local router ID is 9.9.23.3Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 9.9.23.2 0 0 200 iBGP Multipath
https://ipwithease.com/bgp-multipath-scenario/
R1(config)#router bgp 100
R1(config-router)#maximum-paths 2R1#sh ip bgp
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*m 4.4.4.4/32 9.9.12.2 0 200 i <<< ‘m’ means multipath enabled #
*> 9.9.13.3 0 200 iBGP Route Dampening
A route is considered to be flapping when its availability changes repeatedly. Route Dampening is a way to suppress flapping routes so that they are “suppressed” instead of being advertised.
Since BGP routing tables are huge, it’s not practical to send route flaps to neighbors, This could affect the performance of the network as well as consume more routers resources like CPU, As a best practice most ISPs use route dampening regularly.
https://ipwithease.com/bgp-route-dampening-configuration/
router bgp 1
no synchronization
bgp log-neighbor-changes
bgp dampening 10 750 2000 40 <<<
network 1.1.1.0 mask 255.255.255.0
network 192.168.12.0
neighbor 192.168.12.2 remote-as 2
no auto-summary- Penalty should be reduced by half after 10 minutes
- The dampened route must be reused when it reaches value of 750.
- Route should not be used when it reaches 2000 points.
- The routes experiencing Route flaps should not be suppressed for more than 40 minutes
R1#show ip bgp dampening parameters
dampening 10 750 2000 40
Half-life time : 10 mins Decay Time : 1550 secs
Max suppress penalty: 12000 Max suppress time: 40 mins
Suppress penalty : 2000 Reuse penalty : 750BGP backdoor
https://ipwithease.com/understanding-bgp-backdoor/
….The “Backdoor Feature” can be used to up the administrative distance of eBGP to 200 to make sure that IGP learned routes are given priority. This feature means that a backdoor network will be treated like a local one….
R1#
router bgp 100
network 9.9.0.2 mask 255.255.255.255 backdoor
neighbor 9.9.13.3 remote-as 300Impact of Load balancing due neighborship to loopbacks
+ difference between nexthop and advertising router
+ Multipathing to multiple paths through 1 neighbor vs 2 or more neighbors
R3 has connected network 192.168.4.0/24 which is advertised in BGP
ibgp peering is only between R2 and R3,
while R1 and R4 are not participating in BGP
If direct link between R2 and R3 is lost
peering is reestablished via R1 and R4 because of peering using loopbacks
All loopbacks are advertised in IGP Multipath is enabled on R2
1. Given that R2 sees loopback of R3 from R1 and R4, how will bgp packets travel to R3?
2. Will it load balance traffic over both R1 and R4?
3. what will be “BGP” next hop for 192.168.4.0/24 on R2?
BGP control-plane traffic (the TCP session itself)
Usually: no per-packet balancing. Most routers do per-flow hashing for ECMP.
A single BGP session is typically:
- One TCP flow (same src/dst IPs + ports)
- So it gets hashed onto one of the ECMP paths (either via R1 or via R4)
It will only switch if:
- the chosen path fails, or
- the hash outcome changes
Data-plane traffic toward 192.168.4.0/24
Because not true next hop or non connected next hop is always recursively resolved, if the next-hop of ibgp in IGP is ECMP then data will be load balanced per flow.
R2 will forward traffic to the BGP next hop (R3 loopback), and if the IGP has ECMP to that loopback, then traffic to 192.168.4.0/24 can be load-balanced over R1 and R4 (again, typically per-flow hashing).
Important: “maximum-paths / BGP multipath on R2”
That only helps if R2 learns multiple BGP paths for 192.168.4.0/24 (different BGP next-hops, etc.).
Here R2 has only one iBGP neighbor (R3), so it only learns one BGP path. Multipath doesn’t create extra BGP paths; ECMP here comes from the IGP to the BGP next hop.
In case R1 and R4 are running bgp then next hop for 192.168.4.0/24 will be different and advertising router will be R3’s loopback address?
On R2, you will see:
- Next hop: ✅ R3’s loopback
- Advertising neighbor: not R3 but R1 or R4 (whoever sent the update) & RID: RID of R1 or R4
So:
✔ Advertising router ≠ next hop
✔ Next hop still points to R3 unless we use next-hop-self all on ibgp neighbor
✔ Traffic recursively follows IGP to R3 (possibly ECMP via R1/R4)
instances where you will see different next hop compared to advertising router is when route is coming from ebgp to ibgp network, on internal ibgp routes next hop is usually same as advertising router because ibgp never changes next hop when advertising to neighbor
CCIE DHCP
DHCP
DHCP Client uses source port 68 and destination UDP port 67
DHCPDISCOVER
DHCPDISCOVER is a broadcast message to 255.255.255.255 and MAC address FFFF:FFFF:FFFF, The source IP address is 0.0.0.0, and the source MAC address is the MAC address of the sending device
DHCPOFFER
DHCP server if on subnet or remote, responds with DHCPOFFER, if more than one DHCP servers respond then client typically selects the server that sent the first DHCPOFFER response it received
DHCPREQUEST
DHCP client selects a server and responds by sending a broadcasted DHCPREQUEST message indicating that it will be using the address provided in the DHCPOFFER
DHCPDECLINE
This message is sent from a client to a DHCP server to inform the server that an IP address is already in use on the network.
DHCPACK
DHCP server responds to the client with a DHCPACK message indicating that the IP address is leased to the client and includes any additional DHCP options
DHCPNAK
A DHCP server sends this message to a client and informs the client that the DHCP server declines to provide the client with the requested IP configuration information.
DHCPRELEASE
A client sends this message to a DHCP server and informs the DHCP server that the client has released its DHCP lease, thus allowing the DHCP server to reassign the client IP address to another client.
DHCPINFORM
A client sends this message to a DHCP server and requests IP configuration parameters. Such a message might be sent from an access server requesting IP configuration information for a remote client attaching to the access server.
DHCP relay
If DHCP server is located in remote subnet then it gateway on client’s subnet need to have DHCP relay agent configured in order to forward the broadcast packets as unicast packets to the server
Routers dont just relay DHCP but can also relay following protocols to remote servers
- TFTP
- Domain Name System (DNS)
- Internet Time Service (ITS)
- NetBIOS name server
- NetBIOS datagram server
- BootP
- TACACS
Router interface as DHCP client
Router or switch can act as DHCP client to obtain IP address on its own interface “ip address dhcp”
Router interface as DHCP server
When router or switch is configured as a DHCP and pool is configured, excluding IP address with “ip dhcp excluded-address 10.8.8.1 10.8.8.10”, command prevents DHCP from assigning those IP addresses to a client. Note that you do not have to include the IP address of the router interface in this exclusion because the router never hands out its own interface IP address.
Potential DHCP issues
Helper address not configured: Router not configured with helper address under the interface facing clients – dhcp relay not configured
Incorrect Server configured: Incorrect DHCP server IP configured under helper address
Pool missing from DHCP server: Request originating from VLAN does not exist on DHCP server as pool, that VLAN or interface must also have IP address and helper configured
Pool exhaustion: DHCP pool could be out of IP addresses – pool exhaustion
High lease duration can cause pool exhaustion: A too high lease duration may cause pool exhaustion if you have more clients than the pool can support
Consider a wireless network at an airport. Let’s say there are 4096 addresses in the pool with a lease duration of 12 hours. Since users are typically not in an airport for more than 4 hours, this lease duration is too long, and the IP address will still be leased to that user until the lease expires, even if the user is no longer in the airport. Therefore, as the day progresses, more addresses are leased, until the pool is exhausted. So, setting a lower lease duration, such as 3 hours, would ensure that the lease expires sooner rather than later and helps prevent pool exhaustion.
Duplicate IP addresses: A DHCP server might hand out an IP address to a client that is already statically assigned to another host on the network. These duplicate IP addresses can cause connectivity issues for both the DHCP client and the host that was statically configured for the IP address.
Multicast
Multicast
It allows a source to send packets to a group of destination hosts (receivers) in an efficient manner
IGMP operates on Layer 2 (on receivers’ side)
PIM operates on Layer 3 (Routed network)
Multicast starts from source and then branch out to receivers top to bottom
Multicast Source sits behind a router called First-Hop router or FHR
Router that has receivers connected is called Last-Hop router or LHR
on its LAN side it will have IGMP enabled, and also a role called IGMP querier will be active on that LAN side
Between these 2 routers, PIM will operate
Switch will run IGMP snooping in order to snoop the IGMP messages
Without Mutlicast
the network link between R1 and R2 needs 50 Mbps of bandwidth
Stream of data is sent to special addresses called group addresses
Local network control block 224.0.0.0 to 224.0.0.255
Addresses in the local network control block are used for “control traffic” which is not forwarded outside of a local broadcast domain.
Examples of this type of multicast control traffic are:
1. all hosts in this subnet (224.0.0.1)
2. all routers in this subnet (224.0.0.2)
3. all PIM routers (224.0.0.13)
Control traffic sent out on this range has TTL of 1 and packet expires as soon as it enters next hop router, you might think that packers from 224.0.0.0 network cannot propagate through the network? even though the packet expires reaching next router but that “control” message is delivered through out the network router by router using these packets with TTL of 1
224.0.0.1 – all hosts in this subnet (all hosts listen on this address)
224.0.0.2 – all routers in this subnet
224.0.0.5 – all OSPF routers (AllSPFRouters)
224.0.0.6 – all OSPF DRs (AllDRouters)
224.0.0.10 – all EIGRP routers
224.0.0.13 – all PIM routers
224.0.0.18 – VRRP
224.0.0.22 – IGMPv3
224.0.0.102 – HSRPv2 and GLBP
Internetwork control block (224.0.1.0/24):m
Addresses in the internetwork control block are used for “control traffic” that may be forwarded through the Internet. Examples include Network Time Protocol (NTP) (224.0.1.1), Cisco-RP-Announce (224.0.1.39), and Cisco-RP-Discovery (224.0.1.40).
224.0.1.1 – NTP
224.0.1.39 – Cisco-RP-Announce (Auto-RP)
224.0.1.40 – Cisco-RP-Discovery (Auto-RP)
Source Specific Multicast (SSM) block
232.0.0.0 to 232.255.255.255 232.0.0.0/8
This is the default range used by SSM. SSM is a PIM extension
SSM forwards traffic only from sources for which the receivers have explicitly expressed or chosen, for example, receivers input the sender address in the software. Used for one-to-many applications.
Administratively scoped block 239.0.0.0 to 239.255.255.255
This range is like private 10.0.0.0/8 range that can be used for multicasting internally in organsiation’s network and is used for normal multicasting or non SSM
Multicast & Layer 2
In order for multicast packets to be delivered to end hosts, their NIC needs to listen to “Multicast Group’s MAC address”
The first 24 bits of a multicast MAC address always start with “01:00:5E”
This is very much like “OLOOSE”
That “01” is Individual / Group bit (group means multicast group)
remaining 23 bits of the MAC address come from the lower 23 bits of the IPv4 multicast address.
“an example of mapping the multicast IP address 239.255.1.1 into the multicast MAC address 01:00:5E:7F:01:01”
When bits from IP address (top row) are transfered down into last 23 bits with first 24 bits 01:00:5E: and one individual / group bit (total 24 + 1 = 25 bits)
“some multicast group IP addresses can map to single MAC address“
because first 9 bits of the multicast IP address are not copied into the multicast mac address because of this phenomenon there are 32 (25) multicast IP addresses that are not universally unique and could correspond to a single MAC address or overlap, this can result in some machines which are subscribed to one multicast address, also receive multicast for another IP address
To keep it all simple just imagine that due to 01:00:5E (0LOOSE) only last 23 bits are copied from IP address
When a receiver wants to receive a specific multicast feed, it sends an IGMP join using the multicast IP or group address
The receiver programs its interface to accept the multicast MAC group address that correlates to the group address
IGMPv2
Receivers use IGMP to join multicast groups and leave multicast groups,
When a receiver wants to receive multicast traffic from a source, it sends an IGMP join to its router. If the router does not have IGMP enabled on the interface, the request is ignored.
Most common IGMP version is IGMPv2
IGMPv3 is used by SSM
IGMPv2 uses “packet” that travels to the router with TTL of 1,
if a router is the one that decremented the TTL from 1 to 0,
that router does not proceed with forwarding / routing of that packet and that packet is then discarded.
Type Field
Version 2 membership report
also known as IGMP join , remember M in IGMP for Membership
used by receivers to join a multicast group
or to respond to a local router’s membership query message
Version 1 membership report
is used by receivers for backward compatibility with IGMPv1
Version 2 leave group
is used by receivers to indicate they want to stop receiving multicast traffic for a group they joined.
General membership query is periodically sent to the all-hosts group address 224.0.0.1 to see whether there are any receivers in the attached subnet. It sets the group address field to 0.0.0.0 (and not to a specific group address).
Group specific query is sent in response to a leave group message to the group address the receiver requested to leave, this is a test by local router to see if there are any more receivers on LAN and if this leaving router is the last receiver.
Upstream after receiving IGMP join message from LAN
The local router once receives an IGMP join message on LAN side then sends a PIM join message upstream toward the source to request the multicast stream
When the local router starts receiving the multicast stream, it forwards it downstream to the subnet where the receiver that requested it resides.
Router then starts periodically sending general membership query messages into the subnet, to the all-hosts group address 224.0.0.1, to see whether any members are in the attached subnet. The general query message contains a max response time field that is set to 10 seconds by default
In response to this query, “receivers” set an internal random timer between 0 and 10 seconds (which can change if the max response time is using a non-default value). When the timer expires, receivers send membership reports for each group they belong to. If a receiver receives another receiver’s report for one of the groups it belongs to while it has a timer running, it stops its timer for the specified group and does not send a report; this is meant to suppress duplicate reports from everybody
When the leave group message is received by the router, it follows with a group-specific membership query to the group multicast address to determine whether there are any receivers interested in the group remaining in the subnet. If there are none, the router removes the IGMP state for that group.
IGMP querier election (if there is more than one IGMP router on segment)
If there is more than one router in a LAN segment, an IGMP querier election takes place to determine which router will be the querier.
IGMPv2 routers send general membership “query” messages destined to the 224.0.0.1 multicast address
When an IGMPv2 router receives such a message, It cannot receive this “query” message, as host only “report” and not “query” that means there is another router on thet network
The router with the lowest (Layer 2) interface IP address in the LAN subnet is elected as the IGMP querier.
All the non-
querier routers (routers that did not have lowest IP and lost) start a timer that resets each time they receive a membership query report from the querier router.
If the querier router stops sending membership queries for some reason (for instance, if it is powered down), a new querier election takes place. A non-querier router waits twice the query interval, which is by default 60 seconds, and if it has heard no queries from the IGMP querier, it triggers IGMP querier election.
IGMPv3
In IGMPv2, when a receiver sends a membership report to join a multicast group, it does not specify which source it would like to receive multicast traffic from. IGMPv3 is an extension of IGMPv2 that adds support for multicast source
gives the receivers the capability to pick the source they wish to accept multicast traffic from, it could be sender in same group such as 239.0.0.12 but receiver has ability to receive from better sender
IGMPv3 is designed to coexist with IGMPv1 and IGMPv2
IGMPv3 sources can be mentioned by receivers in following ways:
Include mode: In this mode, the receiver announces membership to a multicast group address and provides a list of source addresses (the include list) from which it wants to receive traffic.
Exclude mode: In this mode, the receiver announces membership to a multicast group address and provides a list of source addresses (the exclude list) from which it does not want to receive traffic. The receiver then receives traffic only from sources whose IP addresses are not listed on the exclude list. To receive traffic from all sources, which is the behavior of IGMPv2, a receiver uses exclude mode membership with an empty exclude list.
IGMPv3 is used to provide source filtering for Source Specific Multicast (SSM).
IGMP Snooping
To optimize forwarding and remove flooding, switches need a method of sending traffic only to interested receivers.
A multicast MAC address is never used as a source MAC address
And because multicast mac address is never seen as source MAC address, and never learned (because of source based learning), multicast frame going into the switch as destination is treated as unknown frame and flood them out all ports just like broadcast
IGMP snooping works by examining IGMP joins sent by receivers and maintaining a table of groups, IGMP groups and interfaces. When the switch receives a multicast frame destined for a multicast group, it forwards the packet only out the ports where IGMP joins were received for that specific multicast group
source sending traffic to 239.255.1.1 (01:00:5E:7F:01:01). Switch 1 receives this traffic, and it forwards it out only the g0/0 and g0/2 interfaces because those are the only ports that received IGMP joins for that group.
Even with IGMP snooping enabled, some multicast groups are still flooded on all ports (for example, 224.0.0.0/24 reserved addresses Local Network Control Block).
If IGMP snooping is not enabled, then a static entry can also be added in mac address table. A multicast static entry can also be manually programmed into the MAC address table, but this is not a scalable solution because it cannot react dynamically to changes; for this reason, it is not a recommended approach.
Protocol Independent Multicast
PIM uses routing table already built that is why it is called Protocol Independent
PIM works at Layer 3
The two basic types of multicast distribution trees are
source trees as shortest path trees (SPTs), and shared trees (not shortest)
Source Trees or Shortest Path Tree SPT
A source tree or SPT or (S,G) is a multicast distribution tree where the source is the root of the tree, and branches form a distribution tree through the network towards receivers. When this tree is built, it has the shortest path through from the source to the leaves of the tree; for this reason, it is also referred to as a shortest path tree (SPT).
Forwarding state of the SPT is known by the notation (S,G), pronounced “S comma G,” where S is the sender of the multicast stream (server), and G is the multicast group address
Notice that this is Specific source / sending server per group, if a new server or sender is created, a new (S,G) will need to be built
Shared Trees or Rendezvous Point Trees RPT
A shared tree or (*,G) is a multicast distribution tree where the root of the shared tree is not the source but a router designated as the rendezvous point (RP) is, For this reason, shared trees are also referred to as rendezvous point trees (RPTs)
Multicast traffic is forwarded to RP even if source is next to receivers because of shared tree
shared tree is referred to by the notation (*,G), pronounced “star comma G.”
notice that it is “any” source per group
RP keeps record of all the senders (while R1 only has record of its sender) and is also responsible for receiving all Mcast streams, and then forwarded out of the RP
One of the benefits of shared trees over source trees is that they require fewer multicast entries (for example, S,G and *,G). For instance, as more sources are introduced into the network, sending traffic to the same multicast group, the number of multicast entries for R3 and R4 always remains the same: (*,239.1.1.1)
The major drawback of shared trees is that the receivers receive traffic from all the sources sending traffic to the same multicast group. Even though the receivers’ applications can filter out the unwanted traffic, this situation still generates a lot of unwanted network traffic, wasting bandwidth. In addition, because shared trees can allow all sources in an IP multicast group, there is a potential network security issue because unintended sources could send unwanted packets to receivers.
PIM Terminology
This diagram should be read from top or source to down, all the roles are from top to bottom such as First-hop Router
Reverse Path Forwarding (RPF) interface
The interface with the lowest-cost path to the IP address of the source (SPT) or the RP, If multiple interfaces have the same cost, the interface with the highest IP (Layer 3) address is chosen as the tiebreaker
Also known as the incoming interface (IIF) (Incoming interface because this is where incoming multicast traffic will come), The only type of interface that can accept multicast traffic coming from the source, which is the same as the RPF interface. An example of this type of interface is Te0/0/1 on R3 because the shortest path to the source is known through this interface.
Another example of this type of interface is Te0/1/2 on R5 because it is the shortest path to the source. Another example is Te1/1/1 on R7 because the shortest path to the source was determined to be through R4.
RPF neighbor
The PIM neighbor or PIM enabled router on the RPF interface, if R7 is using the RPT shared tree, the RPF neighbor would be R3, which is the lowest-cost path to the RP. If it is using the SPT, R4 would be its RPF neighbor because it offers the lowest cost to the source.
A PIM join always travels upstream toward the source
Downstream interface
Any interface that is used to forward multicast traffic down the tree, also known as an outgoing interface (OIF). An example of a downstream interface is R1’s Te0/0/0 interface, which forwards multicast traffic to R3’s Te0/0/1 interface.
Outgoing interface (OIF)
Any interface that is used to forward multicast traffic down the tree, also known as the downstream interface.
Outgoing interface list (OIL)
A group of OIFs that are forwarding multicast traffic to the same group. An example of this is R1’s Te0/0/0 and Te0/0/1 interfaces sending multicast traffic downstream to R3 and R4 for the same multicast group.
Last-hop router (LHR)
A router that is directly attached to the receivers, also known as a leaf router. It is responsible for sending PIM joins upstream toward the RP or to the source.
First-hop router (FHR)
A router that is directly attached to the source, also known as a root router. It is responsible for sending register messages to the RP.
Multicast Routing Information Base (MRIB)
A topology table that is also known as the multicast route table (mroute). It is built based on information from the unicast routing table and PIM. MRIB contains the
source S, group G,
incoming interfaces (IIF),
outgoing interfaces (OIFs),
and RPF neighbor information
for each multicast route as well as other multicast-related information.
Multicast Forwarding Information Base (MFIB)
A forwarding table that uses the MRIB to program multicast forwarding information in hardware for faster forwarding.
There are currently five PIM operating modes:
- PIM Dense Mode (PIM-DM) or ASM (Any Source Multicast)
- PIM Sparse Mode (PIM-SM)
- PIM Sparse Dense Mode
- PIM Source Specific Multicast (PIM-SSM) or ASM (Any Source Multicast)
- PIM Bidirectional Mode (Bidir-PIM)
PIM-DM and PIM-SM are also commonly referred to as any-source multicast (ASM)
All PIM control messages use the IP protocol number 103
they are either unicast (higher TTL)
or multicast, with a TTL of 1 to the all PIM routers address 224.0.0.13
PIM Hello and Neighborship
PIM hello messages are sent by default every 30 seconds out each PIM-enabled interface to learn about the neighboring PIM routers on each interface to the all PIM routers address 224.0.0.13 (all PIM routers)
In both PIM-SM and PIM-DM, PIM neighborship is created the same way:
when directly connected routers running PIM exchange PIM Hello messages on an interface.
The difference between Sparse Mode and Dense Mode is how multicast forwarding works afterward—not how neighbors form.
When is a PIM neighborship created?
A PIM neighborship forms when:
1️ PIM is enabled on an interface
2 Another router on the same subnet also has PIM enabled
3 They exchange PIM Hello packets
These Hellos are sent to:
IPv4: 224.0.0.13
IPv6: FF02::D
Once received, routers become PIM neighbors (adjacent).
No RP, no source, no receiver required to form neighborship
Just PIM enabled + Hello exchange
PIM-SM neighborship (Sparse Mode)
In PIM-SM, neighbors are required to build multicast trees using Join messages.
What happens after neighborship forms?
Depending on router role:
LHR (Last-Hop Router) sends Join toward RP
FHR (First-Hop Router) sends Register to RP
Intermediate routers forward Join/Prune
So flow is:
Enable PIM → Hello exchange → neighborship forms → Join/Register messages start
Key idea:
Sparse Mode builds trees only where receivers exist
PIM-DM neighborship (Dense Mode)
In PIM-DM, neighborship still forms via Hello messages, but forwarding behavior differs.
After adjacency:
Routers immediately:
1 Flood multicast traffic everywhere
2 Then send Prune messages where receivers don’t exist
3 Later send Graft if receivers appear again
So flow is:
Enable PIM → Hello exchange → neighborship forms → Flood traffic → Prune unwanted paths
Key idea:
Dense Mode assumes receivers are everywhere first
Hello messages are also the mechanism used to elect a designated router (DR)
PIM Dense Mode
PIM Dense Mode (PIM-DM), Dense means that there are Multicast receivers in every subnet of the network, in other words, when the multicast receivers of a multicast group are densely populated across the network.
For PIM-DM, the multicast tree is built by flooding traffic out every interface from the source to every Dense Mode router in the network (forced feed)
As each router receives traffic for the multicast group, it must decide whether it already has active receivers wanting to receive the multicast traffic. If so, the router remains quiet and lets the multicast flow continue. If no receivers have requested the multicast stream for the multicast group on the LHR, the router sends a prune message toward the source.
That branch of the tree is then pruned off or goes offline so that the unnecessary traffic does not continue.
Initial Flooding in PIM-DM
As each router receives the multicast traffic from its upstream neighbor via its RPF interface, it forwards the multicast traffic to all its PIM-DM neighbors, This results in some traffic arriving via a non-RPF interface, as in the case of R3 receiving traffic from R2 on its non-RPF interface. Packets arriving via the non-RPF interface are discarded because it is duplicate traffic and a prune message is prepared
Each router uses Reverse Path Forwarding (RPF) to decide which incoming interface is the correct one for multicast traffic from a particular source.
R3 checks its unicast routing table to see “Which interface would I use to reach the source?”
Route to the source (through R1) is the best path.
So, the interface from R1 is the RPF interface.
The interface from R2 is non-RPF.
That means:
R3 accepts multicast packets coming from R1 (RPF interface)
R3 drops multicast packets received from R2 (non-RPF interface)
These non-RPF multicast flows are normal for the initial flooding of multicast traffic and are corrected by the normal PIM-DM pruning mechanism.
Pruning after Initial Flooding in PIM-DM
Prunes are sent out even the RPF interface when the router has no downstream members that need the multicast traffic, as is the case for R4, which has no interested receivers,
and they are also sent out non-RPF interfaces to stop the flow of multicast traffic that is arriving on non-RPF interface, in case of R3
the resulting topology after all unnecessary links have been pruned off. This results in an SPT from the source to the receiver.
This (S,G) state remains until the source stops transmitting. S is the source IP address and G is the group IP address along with the OIL containing OIF or Outgoing Interfaces and also the Incoming / RPF interfaces
In PIM-DM, prunes expire after three minutes.
This causes the multicast traffic to be reflooded to all routers just as was done during the initial flooding. This periodic (every three minutes) flood and prune behavior is normal and must be taken into account when a network is designed to use PIM-DM.
PIM-DM is applicable to small networks where there are active receivers on every subnet of the network. Because this is rarely the case, PIM-DM is not widely deployed and not recommended for production environments.
PIM Sparse Mode
PIM Sparse Mode (PIM-SM) was designed for networks with multicast application receivers scattered throughout the network—in other words, when the multicast receivers of a multicast group are sparsely populated across the network. However, PIM-SM also works well in densely populated networks. It also assumes that no receivers are interested in multicast traffic unless they explicitly request, it opposite of PIM DM
Just like PIM-DM, PIM-SM uses the unicast routing table to perform RPF checks, and it does not care which routing protocol (including static routes) populates the unicast routing table; therefore, it is protocol independent.
PIM Shared and Source Path Trees
PIM-SM uses an explicit join model where the receivers send an IGMP join to their locally connected router, which is also known as the last-hop router (LHR), and this join causes the LHR to send a PIM join in the direction of the root of the tree, which is either the RP in the case of a shared tree (RPT) or in case of SPT, the first-hop router (FHR) where the source transmitting the multicast streams is connected
A multicast forwarding state is created as the result of these explicit joins
Multicast source sends multicast traffic to the FHR. The FHR then sends this multicast traffic to the RP, which makes the multicast source known to the RP
Receiver sends an IGMP join to the LHR to join the multicast group. The LHR then sends a PIM join (*,G) to the RP, and this forms a shared tree from the RP to the LHR, this (*,G) PIM join would travel hop-by-hop to the RP, building (*,G) on all routers it is passing through.
In essence, two trees are created: an SPT from the FHR to the RP (S,G) and a shared tree from the RP to the LHR (*,G).
multicast starts flowing down from the source to the RP
and from the RP to the LHR and then finally to the receiver.
Remember and also from diagram these S,G and *,G messages always travel in reverse direction of multicast traffic flow
*,G is from LHR to RP and S,G is from RP to FHR
Receiver A attached to the LHR joins multicast group G using IGMP join. The LHR knows the IP address of the “RP for group G” – “there can be different RP per group” and LHR then sends (*,G) PIM join for this “group“ to the RP.
Source for a group G sends a packet, the FHR that is attached to this source creates a “unidirectional ” PIM register tunnel interface that encapsulates the multicast data received from the source in a special PIM-SM (Sparse Mode) message called the register message. The encapsulated multicast data is then unicasted due to tunnel to the RP using the PIM register tunnel. This Multicast packet needs to be encapsulated in a unicast packet to RP, so it is not multicasted through the network below FHR and this PIM register tunnel is for one way traffic (Multicast stream from FHR to RPT inside a tunnel / unicasted to RPT)
When the RP receives a register message, it decapsulates the multicast data packet inside the register message, and if there is no active shared tree because there are no interested receivers, the RP unicasts a register stop message directly to the registering FHR, without traversing the PIM register tunnel, instructing it to stop sending the register messages.
If there is an active shared tree for the group, it forwards the multicast packet down the shared tree, and it sends an (S,G) join back toward the source network S to create an (S,G) SPT. If there are multiple hops (routers) between the RP and the source, this results in an (S,G) state being created in all the routers along the SPT, There will also be a (*,G) in R1 and all of the routers between the FHR and the RP. So how can (*,G) and (S,G) co exist on same router?
(*,G): The “shared tree” state — means “any source for group G.”
It’s built towards the Rendezvous Point (RP) in both forward (Between LHR and RP) and reverse direction (between FHR and RP)?
Used before the specific source is known or joined.
(S,G): The “source tree” state — means “specific source S for group G.”
It’s built directly toward the multicast source between FHR and RPT
1. Initial IGMP Join
Receiver A (host) on R3 sends an IGMP Join for group G.
R3 (the Last-Hop Router, LHR) sends a PIM Join (*,G) upstream — towards the RP (R2).
So:
- R3 and R2 now have (*,G) state entries.
- This builds the shared tree (R3 → R2 → R1).
2. Source Starts Sending
When the multicast source (at R1) begins transmitting for group G:
- R1 (the First-Hop Router, FHR) registers with the RP using a PIM Register message.
- The RP learns that source S exists for group G.
3. Receiver Activity Triggers (S,G) Join
When the RP receives traffic from S, it knows there are active receivers (due to the earlier (*,G) join from R3).
So, the RP sends a PIM (S,G) Join back toward the source network — i.e., towards R1.
This creates:
- An (S,G) entry in R2 and R1 (routers along that source tree path).
- But — crucially — the (*,G) state still remains in R1 (and the path between R1 ↔ R2).
So Why Does (*,G) Exist in R1?
Even though R1 is the first-hop router (directly connected to the source), it forms a (*,G) state because:
- It’s part of the shared tree path from the RP to the source (built earlier when RP didn’t yet know the source existed).
The shared tree extends from RP → R1, so all routers on that path (including R1) must maintain(*,G)state. So this (*,G) is created on all routers around RP in 360 degrees. - Transitions are gradual, not instantaneous — both trees (shared and source) coexist temporarily while the network optimizes to the SPT.
As soon as the SPT is built from the source router to the RP, multicast traffic begins to flow natively from the source S to the RP instead of being encapsulated inside unicast PIM Regsiter tunnel and once the RP begins receiving data natively from source S
it sends a register stop message to the source’s FHR to inform it that it can stop sending the unicast register messages inside a tunnel. At this point, multicast traffic from the source is flowing down the SPT to the RP and, from there, down the shared tree (RPT) to the receiver – register stop message’s only function is to make FHR stop sending register message for speicific group and not to stop multicast operation
The PIM register tunnel from the FHR to the RP remains in an active up/up state even when there are no active multicast streams, and it remains active as long as there is a valid RPF path for the RP.
PIM SPT Switchover
PIM-SM allows the LHR to switch from the RPT (shared tree) to an SPT for a specific source
In Cisco routers, this is the default behavior, and it happens immediately after the first multicast packet is received from the RP via the RPT on LHR, even if shortest parth to the source is through RP.
When the LHR receives the first multicast packet from the RP, it becomes aware of the IP address of the multicast source, at this point LHR sends (S,G) PIM Join towards the “source IP” following routing table (and not RP IP) and that can result in PIM Join going out of a different interface (shorter route) than interface through which RP is reachable
This PIM Join going from LHR to FHR creates (S,G) on all routers in the path
When the LHR receives a multicast packet from the source through the SPT, if the SPT RPF interface differs from the RPT RPF interface, the LHR will start receiving duplicate multicast traffic from the source; at this moment, it will switch the RPF interface to be the SPT RPF interface and send an (S,G) PIM prune message to the RP to shut off the duplicate multicast traffic coming through the RPT.
the shortest path to the source is between R1 and R3; if that link were shut down or not present, the shortest path would be through the RP, in which case an SPT switchover would still take place, even though the path used by the SPT is the same as the RPT.
The PIM SPT switchover mechanism can be disabled for all groups or for specific groups.
If the RP has no other interfaces that are interested in the multicast traffic, it sends a PIM prune message in the direction of the FHR. If there are any routers between the RP and the FHR, this prune message would travel hop-by-hop until it reaches the FHR.
What if SPT switchover takes place and LHR’s RPF incoming interface is same for new source as last RP, Then does the reciever recieve duplicate streams? One stream from new source following the SPT switchover and one stream from RP?
No — the receiver should not continue to receive duplicate streams after the SPT switchover, even if the RPF incoming interface toward the new source is the same as toward the RP.
LHR:
Builds an (S,G) entry
Joins directly toward the source
Sends a (S,G) prune toward the RP, That prune stops the RP path from forwarding traffic downstream.
Designated Routers
When multiple PIM-SM routers exist on a LAN segment, PIM hello messages are used to elect a designated router (DR) to avoid sending duplicate multicast traffic into the LAN (LHR) or to the RP (FHR). “Designated” router on LAN to receive traffic or send traffic, so second router does not duplicate multicast on network.
By default, the DR priority value of all PIM routers is 1, and it can be changed to force a particular router to become the DR during the DR election process, where a higher DR priority is preferred. If a router in the subnet does not support the DR priority option or if all routers have the same DR priority, the highest IP address in the subnet is used as a tiebreaker.
On an FHR, the designated router is responsible for encapsulating in unicast register messages any multicast packets originated by a source that are destined to the RP.
On an LHR, the designated router is responsible for sending PIM join and prune messages toward the RP to inform it about host group membership, and it is also responsible for performing a PIM SPT switchover.
Without DRs, all LHRs on the same LAN segment would be capable of sending PIM joins upstream, which could result in duplicate multicast traffic arriving on the LAN.
On the source side, if multiple FHRs exist on the LAN, they all send register messages to the RP at the same time.
The default DR hold time is 3.5 times the PIM hello interval (PIM Hello is 30 seconds) which makes DR hold time to 105 seconds. If there are no hellos after this interval, a new DR is elected. To reduce DR failover time, the hello query interval can be reduced to speed up failover with a trade-off of more control plane traffic and CPU resource utilization of the router.
Reverse Path Forwarding
Reverse Path Forwarding is a method routers use when multicast traffic arrives on interface and it checks source address against routing table and if this is the interface., if not then interface is non RPF interface.
This is used to prevent loops and also avoid duplicated multicast traffic
If a router receives a multicast packet on an interface it uses to send unicast packets to the source, the packet has arrived on the RPF interface.
Next If the packet arrives on the RPF interface, a router forwards the packet out the interfaces present in the outgoing interface list (OIL) of a multicast routing table entry.
If the packet does not arrive on the RPF interface, the packet is discarded to prevent loops.
RPF check is performed differently for RPT and SPT
If a PIM router has an (S,G) entry present in the multicast routing table (an SPT state), the router performs the RPF check against the IP address of the “source” for the multicast packet.
If a PIM router has no explicit source-tree state, this is considered a shared-tree state. The router performs the RPF check on the address of the RP, which is known when members join the group.
PIM Assert , forwarder role
PIM assert mechanism is used to stop duplicate flows into LAN, well was it not the function of DR? yes DR does its best from control plane perspective to prevent duplicate flows, after DR elections only one router sends out PIM Join to receive traffic only on that specific DR router but in some cases (discussed below) you can still end up having duplicate multicast coming from 2 routers on same LAN and if that happens then this condition is detected and remediated using PIM Assert mechanism
in above figure, Both R2 and R3 receive traffic on their (one and only) RPF interface, as these routers dispatch multicast traffic on LAN, R2’s sent multicast hits R3’s OIF interface (due to LAN) and R3’s sent multicast traffic hits R2’s OIF, this triggers the PIM Assert mechanism on both routers as this should not happen
In other words, they detect a multicast packet for a specific (S,G) coming into their OIF that is also OIF for the same (S,G) (this OIF cannot be also IIF for same group)
R2 and R3 both send PIM assert messages into the LAN. These assert messages “send” each other following inside PIM Assert message to determine which router should forward the multicast traffic to that network segment.
- Administrative distance to source
- Metric or cost to the source (unicast since siurce is unicast address)
- Highest IP address (tie-breaker)
Each router compares its own values with the received values. Preference is given to the PIM message with the lowest AD to the source. If a tie exists, the lowest route metric for the protocol wins; and as a final tiebreaker, the highest IP address is used.
The losing router prunes its interface just as if it had received a prune on this interface, and the winning router is the PIM forwarder for the LAN.
The prune times out after three minutes on the losing router and causes it to begin forwarding on the interface again. This triggers the assert process to repeat. If the winning router were to go offline, the loser would take over the job of forwarding on to this LAN segment after its prune timed out. Remember that anything relying on Prune messages will only last 3 minutes as Prune messages expire in 3 mins
The PIM forwarder concept applies to PIM-DM and PIM-SM. It is commonly used by PIM-DM but rarely required by PIM-SM because duplicate packets can end up in a LAN only if there is some sort of routing inconsistency.
PIM-SM would not send duplicate flows into the LAN as PIM-DM would because of the way PIM-SM operates.
Corner case for PIM-SM to send duplicated Multicast in LAN
PIM-SM will only forward duplicated multicast in LAN because of routing inconsistency only
R1 is the RP
R2 and R4 are running the OSPF, and R3 and R5 are running EIGRP, and this is inconsistency in this network – to be more specific 2 different routing domains on same LAN.
R4 learns about the RP (R1) through R2, and R5 learns about the RP through R3
when R4 sends a PIM join message upstream toward it, it sends the message to the all PIM routers address 224.0.0.13, and R2 and R3 receive it but in PIM-SM PIM join message includes the IP address of the upstream neighbor, also known as the RPF neighbor (which is only one neighbor – PIM neighbor on RPF interface)
R4’s RPF neighbor is R2, and R5’s RPF neighbor is R3
Receiver A and Receiver B join the same group
Receiver A’s IGMP join will cause PIM Join from R4 to both R2 and R3 (because of same LAN) R2 is the only one that will send a PIM join to R1 because PIM join from R4 has header that contains R2 as its RPF neighbor, R3 will not because the PIM join was not meant for it, from R4 it was only meant for R2 (its RPF neighbor) and R2 will send PIM Join message to RP
Similarly IGMP join from receiver B will trigger R5 to send a PIM join to to both R2 and R3, but because PIM SM’s PIM Join has RPF neighbor R3 is specified in packet, R3 is the one that will send a PIM join to R1.
At this point, traffic starts flowing downstream from R1 into R2 and R3, and duplicate packets are then sent out into the LAN and to the receivers.
At this point, the PIM assert mechanism kicks in, R3 is elected as the PIM forwarder, and R2’s OIF interface is pruned, as illustrated in the topology on the right side.
Rendezvous Points
In PIM-SM, it is mandatory to choose one or more routers to operate as rendezvous points (RPs). An RP is a single common root placed at a chosen point of a shared distribution tree, as described earlier in this chapter. An RP can be either configured statically in each router or learned through a dynamic mechanism. A PIM router can be configured to function as an RP either statically in each router in the multicast domain or dynamically by configuring Auto-RP or a PIM bootstrap router (BSR), as described in the following sections.
Note
BSR and Auto-RP were not designed to work together and may introduce unnecessary complexities when deployed in the same network. The recommendation is not to use them concurrently.
Static RP
It is possible to statically configure RP for a multicast group range by configuring the address of the RP on every router in the multicast domain. Configuring static RPs is relatively simple and can be achieved with one or two lines of configuration on each router. If the network does not have many different RPs defined or if the RPs do not change very often, this could be the simplest method for defining RPs. It can also be an attractive option if the network is small.
However, static configuration can increase administrative overhead in a large and complex network. Every router must have the same RP address. This means changing the RP address requires reconfiguring every router. If several RPs are active for different groups, information about which RP is handling which multicast group must be known by all routers. To ensure this information is complete, multiple configuration commands may be required. If a manually configured RP fails, there is no failover procedure for another router to take over the function performed by the failed RP, and this method by itself does not provide any kind of load splitting.
Auto-RP
Auto-RP is a Cisco proprietary mechanism that automates the distribution of group-to-RP mappings in a PIM network. Auto-RP has the following benefits:
- It is easy to use multiple RPs within a network to serve different group ranges.
- It allows load splitting among different RPs.
- It simplifies RP placement according to the locations of group participants.
- It prevents inconsistent manual static RP configurations that might cause connectivity problems.
- Multiple RPs can be used to serve different group ranges or to serve as backups for each other.
- The Auto-RP mechanism operates using two basic components: candidate RPs (C-RPs) and RP mapping agents (MAs).
Candidate RPs
A C-RP advertises its willingness to be an RP via RP announcement messages. These messages are sent by default every RP announce interval, which is 60 seconds by default, to the reserved well-known multicast group 224.0.1.39 (Cisco-RP-Announce). The RP announcements contain the default group range 224.0.0.0/4, the C-RP’s address, and the hold time, which is three times the RP announce interval. If there are multiple C-RPs, the C-RP with the highest IP address is preferred.
Note
The RP announcement can be configured to announce specific multicast groups instead of the default group range 224.0.0.0/4. This allows for having multiple RPs in the network serving different multicast groups, which is useful for RP design.
RP Mapping Agents
RP MAs join group 224.0.1.39 to receive the RP announcements. They store the information contained in the announcements in a group-to-RP mapping cache, along with hold times. If multiple RPs advertise the same group range, the C-RP with the highest IP address is elected.
The RP MAs advertise the RP mappings to another well-known multicast group address, 224.0.1.40 (Cisco-RP-Discovery). These messages are advertised by default every 60 seconds or when changes are detected. The MA announcements contain the elected RPs and the group-to-RP mappings. All PIM-enabled routers join 224.0.1.40 and store the RP mappings in their private cache.
Multiple RP MAs can be configured in the same network to provide redundancy in case of failure. There is no election mechanism between them, and they act independently of each other; they all advertise identical group-to-RP mapping information to all routers in the PIM domain.
Auto-RP mechanism where the MA periodically receives the C-RP Cisco RP announcements to build a group-to-RP mapping cache and then periodically multicasts this information to all PIM routers in the network using Cisco RP discovery messages.
With Auto-RP, all routers automatically learn the RP information, which makes it easier to administer and update RP information. Auto-RP permits backup RPs to be configured, thus enabling an RP failover mechanism.
PIM Bootstrap Router
The bootstrap router (BSR) mechanism, described in RFC 5059, is a nonproprietary mechanism that provides a fault-tolerant, automated RP discovery and distribution mechanism.
PIM uses the BSR to discover and announce RP set information for each group to all the routers in a PIM domain. This is the same function accomplished by Auto-RP, but BSR is implemented in a different way and is not compatible with Auto-RP. BSR is an IETF standard that is part of the PIM Version 2 specification, which is defined in RFC 4601.
The RP set is a group-to-RP mapping that contains the following components:
- Multicast group range
- RP priority
- RP address
- Hash mask length
- SM/Bidir flag
Bootstrap messages (BSMs) originate on the BSR, and they are flooded hop-by-hop by intermediate routers. When a Bootstrap message is forwarded, it is forwarded out of every PIM-enabled interface that has PIM neighbors (including the one over which the message was received). Bootstrap messages use the all PIM routers address 224.0.0.13 with a TTL of 1.
To avoid a single point of failure, multiple candidate BSRs (C-BSRs) can be deployed in a PIM domain. All C-BSRs participate in the BSR election process by sending PIM Bootstrap messages containing their BSR priority out all interfaces.
The C-BSR with the highest priority is elected as the BSR and sends Bootstrap messages to all PIM routers in the PIM domain. If the BSR priorities are equal or if the BSR priority is not configured, the C-BSR with the highest IP address is elected as the BSR.
Candidate RPs
A router that is configured as a candidate RP (C-RP) receives the Bootstrap messages, which contain the IP address of the currently active BSR. Because it knows the IP address of the BSR, the C-RP can unicast candidate RP advertisement (C-RP-Adv) messages directly to it. A C-RP-Adv message carries a list of group address and group mask field pairs. This enables a C-RP to specify the group ranges for which it is willing to be the RP.
The active BSR stores all incoming C-RP advertisements in its group-to-RP mapping cache. The BSR then sends the entire list of C-RPs from its group-to-RP mapping cache in Bootstrap messages every 60 seconds by default to all PIM routers in the entire network. As the routers receive copies of these Bootstrap messages, they update the information in their local group-to-RP mapping caches, and this allows them to have full visibility into the IP addresses of all C-RPs in the network.
Unlike with Auto-RP, where the mapping agent elects the active RP for a group range and announces the election results to the network, the BSR does not elect the active RP for a group. Instead, it leaves this task to each individual router in the network.
Each router in the network uses a well-known hashing algorithm to elect the currently active RP for a particular group range. Because each router is running the same algorithm against the same list of C-RPs, they will all select the same RP for a particular group range. C-RPs with a lower priority are preferred. If the priorities are the same, the C-RP with the highest IP address is elected as the RP for the particular group range.
Figure 13-23 illustrates the BSR mechanism, where the elected BSR receives candidate RP advertisement messages from all candidate RPs in the domain, and it then sends Bootstrap messages with RP set information out all PIM-enabled interfaces, which are flooded hop-
by-hop to all routers in the network.
Multicast Listener Discovery (MLD)
Multicast Listener Discovery (MLD) is the IPv6 equivalent of IGMP (Internet Group Management Protocol) used in IPv4. It allows IPv6 hosts to signal their interest in receiving multicast traffic and enables routers to learn which multicast groups have active receivers on a link.
It operates between hosts and LHR, not between routers themselves.
MLD supports
PIM-SM (Protocol Independent Multicast – Sparse Mode)
PIM-SSM (Source-Specific Multicast)
Application → Multicast Group Join
↓
Host sends MLD Report
↓
Router updates membership table
↓
Router builds multicast forwarding tree (via PIM)Step 1: Router Sends Query
Router periodically transmits: MLD General Query
Step 2: Host Responds with Report
Interested hosts reply: MLD Report: Join FF3E::1
MLD Snooping
Switches can inspect MLD messages using MLD snooping.
MLD Packet Characteristics:
- Encapsulated inside ICMPv6
- Sent with hop limit = 1
- Operate only on the local link
- Use link-local scope addresses
Multicast commands
Using Cisco routers as hosts for Multicast send and Multicast receive
no ip routing
ip default-gateway x.x.x.xBasic PIM-DM configuration
no ip pim autorpmore…
coming soon
SDA LM4 – DNAC Web Interface
Videos
Introduction to UI
You can modify these authentication templates but cannot define more
If you want to define different SSID in europe or you want different ISE server for europe then use hierarchy and go to site specific level and override
IP based access control is used when you create non fabric based wireless and this is a very specific use, if we dont use non-fabric wireless then we will not have to touch this page
AI Endpoint Analytics
With new DNAC, AI Endpoint Analytics was introduced and this leverages AI capabilities in cloud and uses deep packet inspection in Catalyst 9K infrastructure to “identify types of endpoints” – this information can then be fed to ISE and can then be used as part of endpoint authentication, this provides additional network packet level context along side the profiling probes that ISE performs on its own and that information is communicated to ISE using PXGrid
Application policies is the feature that was known as Easy QoS and it allows you to deploy QoS end to end in your network, for more details checkout RS0122 – SDA Application Policy (EasyQoS)
Traffic Copy is the way to span traffic from Fabric to a remote destination and this is part of SGT, as you can capture traffic between specific contracts or tags
Finally Virtual networks which are essentially VRFs and separate different (virtual) fabric on same network
Service catalog, these are different services that are offered
User defined network is a cool concept as it allows users to create personal network on top of shared infrastructure, users can then register their personal devices using an app and also invite other users into that network using same app and these networks are like bubbles
These 4 services are also listed under the services section of provision tab
Assurance does not just measures health and experience of network devices but also includes clients and helps us measure client’s experience on the network also and it does not stay at client but its scope one level more deep into application as well
Events are for both Network devices and also for the clients, these are any events that happen in the network for network devices and its connected clients
DNAC offers dedicated sensors that can perform series of tests to gauge performance from client perspective. These wireless sensors join network as wireless device and these can either be dedicated sensors or an AP can also be converted to a wireless sensor
Wi-Fi6 section is for Wi-Fi6 readiness assessment which shows us the percentage of AP and clients that are capable of Wi-Fi6, if large number of clients support Wi-Fi6 then we can think about more APs to be deployed that support Wi-Fi6
Dashboard Library is where we can create our own dashboards
This Trends and Insights leverage AI in Cloud and Machine learning to spot issues in network,
Trends and Insights deals with deviation in capacity and performance
Site comparison shows us how one site compares to another, as in some cases one site can perform worse than the others
Issue settings is where we can control what issues such as P1 and P2 can be raised by DNAC such as Assurance > Issues & Events, we can enable or disable some of these issues if they are not important to us, we can also change priority on them
Health score is where you can turn on or off on what is included in determining device health score, these health score threshold values can be modified as well
Sensor section here we define test settings such as ping, HTTPs, association test etc
Intelligent capture is where you define how and when you want your AP to perform capture of client traffic
Workflows make things easy for us as they are guided configuration wizards that help us configure things easily and quickly without making mistakes
CLI templates is where we create templates, when it is time to apply template then we apply them using Network profiles
Feature templates are graphical UI based configuration unlike CLI template and they dictate best practice rather than manual CLI based templates, this makes configuration like Meraki but we only have this wireless at the moment
Network reasoner helps troubleshoot offered issues in Network reasoner dashboard
Platform section allows us to use DNAC API for automation and API interaction, it is also used to install device packs for non Cisco devices and also 3rd Party integration such as service now
DNAC comes with report templates
Cisco.com Credentials
Cisco credentials is the same credentials we entered after changing password for DNAC admin on first time login
PnP Connect
PnP connect lets you sync your devices from internet based Cisco’s PnP to DNAC directly, this is used for onboarding routers and switches using PnP in Cloud
Cisco Plug and Play (PnP) Connect is a cloud-based onboarding service that helps you automatically provision new Cisco network devices (switches, routers, access points, etc.) with Cisco DNA Center — no manual configuration or console access needed similar to SDWAN or Meraki onboarding
When a new Cisco device boots up:
- It connects to the PnP Cloud portal.
- The PnP Cloud checks the device’s serial number.
- The device is matched to your DNA Center project.
- The device is redirected to your DNA Center for zero-touch provisioning.
Smart account
“Auto register smart license enabled devices” allows devices to register to selectable “Virtual account inside the Smart account”
Smart Licensing
Smart account defined earlier is used in Smart licensing section, register a smart account and virtual account to have DNAC licensed and in compliance state
Device EULA Acceptance
For LAB I will not accept as not sure what might be the impact on CCO account against licenses
Image Distribution Servers
10.21.1.2 (LOCAL) is DNAC itself, but we can define other image distribution servers not to burden the WAN
Network Resync Interval
This is how often DNAC syncs with network devices, default is 24 hours
SNMP
is timeouts and retires
Authentication and Policy Servers
defined ISE servers
Cisco AI Analytics
This is where you configure AI analytics
Destinations
This is to deliver event notifications when events happen on DNAC
Integrity Verification
Checks if device is compromised on software, hardware level using Known Good Values KGV file from Cisco, which also requires updates from Cisco
IP Address Manager
This is integration with IPAM
Machine Reasoning Engine
Download and keep upto date Cisco’s latest machine learned troubleshooting and reasoning database, make sure it is set to auto update
Debugging Logs
This is to debug logs for DNAC itself, specify a syslog server
Search
Search in DNAC is amazing and you can search clients by MAC address or IP address / track clients with Client 360 link in search result and even search IP pools
API Reference
This comes handy when you are working with API
SDA LM5 – SDA Fabric Virtual Networks
Videos
SDA Fabric Virtual Networks
Fabric Site
Fabric Site contains its own components such as border node, control node, access switches and Wireless controllers – imagine a typical site or building or campus that has network components
A fabric site can span multiple building but only over a high speed, low latency network and not WAN connection
Transit Network
Transit Network either connects multiple Fabric Sites together or connects a Fabric site to an external network
and there are different types of transit networks which will be discussed
Fabric Domain
Fabric Domain is made up of one or more Fabric Sites
Geographic distance between buildings and location decides the fabric site’s boundary
Type of WAN decides the Transit Network type
Depending on the version of SDA and cisco documentation, fabric site can only be so big and scale, if fabric site is bigger than what is supported by SDA, then you will have to break up the single fabric site into 2 Fabric sites
So make sure to check scalability number in Cisco documentation
Make sure you have all devices that will be part of the fabric already discovered, reachable, managed and synced and LAN Automated, preferable compliant also
- Second most important thing is that, make sure that your edge devices do not have a route to DNAC via their default route and must have a specific route, I learned this the hard way
SDA-HQ-FES-01#show ip route 10.21.1.2
% Network not in tableSDA-HQ-FBS-01
conf t
ip route 10.21.1.0 255.255.255.0 172.17.0.3
!
router isis
redistribute static ipSDA-HQ-FES-01#show ip route 10.21.1.2
Routing entry for 10.21.1.0/24
Known via "isis", distance 115, metric 10, type level-2
Redistributing via isis
Last update from 172.16.0.72 on GigabitEthernet1/0/4, 00:00:05 ago
Routing Descriptor Blocks:
* 172.16.0.74, from 172.16.0.64, 00:00:05 ago, via GigabitEthernet1/0/3
Route metric is 10, traffic share count is 1
172.16.0.72, from 172.16.0.64, 00:00:05 ago, via GigabitEthernet1/0/4
Route metric is 10, traffic share count is 1SDA-HQ-FES-01#ping 10.21.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 114/131/164 msSDA-HQ-FES-01#ping 10.21.1.2 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.1.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.71
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 111/122/134 ms
DNAC comes with default LAN fabric
We can either choose to use this or create a new fabric
We should always create a new fabric and not use the default
service unsupported-transceiver
service unsupported-transceiver
in some switches such as nexus, this command is applied under interface rather than global command
SDA list all mac addresses under a specific VLAN/LISP instances
On All FES switches run this command to collect the LISP instances
show lisp instance-id * ethernet database | include VlanThen on FBS check all the mac addresses under specific VLAN / LISP Instance
show lisp instance-id 8191 ethernet serverDevice Telemetry issue
WLC telemtry issue
provision > inventory > select WLCs >
actions > telemtry > update telem settings > check the push config button > deploy
show telemetry internal connectiondot1x, mab, authenitcation, access-session commands
Command
authentication periodicEnables periodic reauthentication of connected devices.
-The switch forces the endpoint to re-authenticate at regular intervals.
-Helps ensure that access permissions stay valid.
-The interval is usually controlled by the RADIUS server (or another timer setting).
Example use case:
If a device changes security posture (e.g., antivirus disabled), access can be revoked after reauthentication.
authentication timer reauthenticate serverTells the switch to use the reauthentication interval provided by the RADIUS server instead of a locally configured timer.
Common when using Cisco ISE.
Ensures centralized control of session refresh timing.
access-session inherit disable interface-template-stickyPrevents the port from inheriting sticky interface-template settings after authentication.
Why useful
Avoids persistent policy settings staying applied after the session ends.
access-session inherit disable autoconfStops automatic inheritance of autoconfiguration session settings.
Why useful
Gives tighter manual control over authentication behaviour on the interface.
access-session port-control autoSets the port to automatic authentication mode.
Meaning:
Port starts unauthorized
Device must authenticate
Access granted only after successful authentication
This is the standard mode for secure access ports.
Other possible modes (for reference):
| Mode | Behaviour |
|---|---|
| auto | Authenticate before allowing access |
| force-authorized | Always allow access |
| force-unauthorized | Always block access |
mabEnables MAC Authentication Bypass for devices without supplicant
Used when a device does NOT support 802.1X, such as:
printers
IP phones
IoT devices
cameras
Instead of credentials, the switch sends the MAC address to the RADIUS server for authentication.
Typical workflow:
Switch tries 802.1X
If no response → fallback to MAB
MAC checked in RADIUS database
dot1x pae authenticator| Role | Device |
|---|---|
| Supplicant | Client device |
| Authenticator | Switch |
| Authentication server | RADIUS / ISE |
Configures the switch port as an 802.1X authenticator.
This command enables the switch to perform authentication enforcement.
dot1x timeout tx-period 5Sets the interval between EAP request transmissions to 5 seconds.
0 sec → request sent
5 sec → request sent again
10 sec → request sent again
This controls the gap between attempts.
dot1x timeout supp-timeout 5Sets how long the switch waits for a supplicant response before retrying.
Example:
If client doesn’t respond in 5 seconds → retry
dot1x max-req 3Maximum number of authentication request retries sent to the supplicant.
After 3 failures:
Switch may fall back to MAB (if enabled).
Retries up to 3 times If no response → tries MAB
dot1x max-reauth-req 3Maximum number of retries during reauthentication attempts.
If exceeded:
Session may be terminated or fallback triggered depending on policy.
Putting timers together
Switch sends request
Waits 5 seconds (supp-timeout)
Retry after 5 seconds gap (tx-period)
Repeat up to 3 times (max-req)
tx-period – How often I ask – this will be continuous process when port comes up
supp-timeout – How long I wait – this is what triggers retries
Retries are controlled by max-req, and the spacing between retries is controlled by tx-period.
supp-timeout only controls how long the switch waits for a response after sending each request. supp-timeout simply marks the device as having no supplicant
dot1x timeout supp-timeout 3
dot1x timeout tx-period 10
dot1x max-req 3t=0 send request
t=3 no reply → supp-timeout expires
t=10 next retry sent (tx-period controls this)
t=13 no reply → supp-timeout expires
t=20 next retry sent
t=23 no reply → supp-timeout expires
STOP (max-req reached)
more…
coming soon
SDA Fundamentals
SDA Fundamentals
more…
coming soon
SDA Deploy
SDA Deploy
TBD – to be done
more…
coming soon
Cisco | Compare ISE Posture Redirection Flow to ISE Posture Redirectionless Flow, pre and post ISE 2.2
Redirection vs Redirectionless
A new functionality introduced in Identity Service Engine (ISE) 2.2 that allows ISE to support a posture flow without any kind of redirection on either a Network Access Device (NAD) or ISE.
- ISE as a policy configuration distribution and decision point.
On ISE, you configure
posture policies (what exact conditions must be met to mark a device compliant),
client provisioning policies (what agent software must be installed on what kind of devices), and
authorization policies (what kind of permissions must be assigned to, depends upon their posture status). - A network access device as a policy enforcement point.
On the switch or wlc, actual authorization restrictions are applied at the time of user authentication. ISE provides authorization parameters like Downloaded ACL (dACL)/VLAN/Redirect-URL/Redirect Access Control List (ACL).
Traditionally, in order for posture to happen, NADs are required to support redirection and Change of Authorization (CoA) to reauthenticate the user after the posture status of the endpoint is determined. - Agent receives information about posture requirements from the ISE and provides a report to the ISE about the status of the requirements.
In the pre-ISE 2.2 flow posture, NADs are not only used to authenticate users and restrict access, but also to provide information to agent software about a specific ISE node that must be contacted (through the use of redirect ACL). As part of the redirection process, the information about the ISE node is returned to the agent software.
Historically, redirection support (either on the NAD or ISE side) was an essential requirement for posture implementation. In ISE 2.2 requirement to support redirection is eliminated for both the initial client provisioning and posture process.
Client provisioning without redirection – In ISE 2.2 you can access the Client Provisioning Portal (CPP) directly via the portal Fully Qualified Domain Name (FQDN). This is similar to the way you access Sponsor Portal or MyDevice Portal.
Posture process without redirection – During agent installation from the CPP portal information about ISE servers is saved on the client side which makes direct communication possible.
Posture Flow Pre ISE 2.2
This image shows a step-by-step explanation of the Anyconnect ISE Posture Module flow prior to ISE 2.2:
Step 1. Authentication is the first step of the flow, it can be dot1x, MAB, or VPN.
Step 2. ISE needs to choose an authentication and authorization policy for the user. In the posture scenario, chosen authorization policy must contain a reference to the posture status, which initially must be either unknown or not applicable. To cover both these cases, conditions with posture status unequal compliance can be used.
The authorization profile must contain following:
- Web Redirection- For the posture case, the web redirection type: client provisioning (posture).
- ACL- This section needs to contain the ACL name which is configured on the NAD side. This ACL is used to instruct NAD which traffic must bypass the redirection and which must be actually redirected.
- DACL- It can be used together with redirect access-list but consider that different platforms process DACL and Redirect ACLs in a different order.
For example, ASA always processes DACL before it redirects ACL. At the same time, some switch platforms process it in the same way as ASA, and other switch platforms process Redirect ACL first and then check DACL/Interface ACL if traffic must be dropped or allowed.
Note: After you enable the web redirection option in the authorization profile, the target portal for redirection must be chosen.
Step 3. ISE returns Access-Accept with authorization attributes. Redirect URL in authorization attributes is automatically generated by ISE. It contains these components:
- FQDN of ISE node on which authentication happened. In some cases, dynamic FQDN can be overwritten by Authorization profile configuration (Static IP/Hostname/FQDN) in the Web Redirection section.
If the static value is used it must point to the same ISE node where authentication was processed.
Step 4. NAD applies an authorization policy to the session. Additionally, if DACL is configured, its content is requested before authorization policies are applied.
Important considerations:
- All NADs- Device must have locally configured ACL with the same name as the one received in Access-Accept as redirect-acl.
- Switches- The IP address of the client must be presented in the output of
show authentication session interface detailscommand to successfully apply redirection and ACLs. The client IP address is learned by IP Device Tracking Feature (IPDT).
Step 5. The client sends a DNS request for the FQDN which is entered into the web browser. At this stage, DNS traffic must bypass redirection and the correct IP address must be returned by the DNS server.
Step 6. The client sends TCP SYN to the IP address which is received in the DNS reply. The Source IP address in the packet is the client IP and the Destination IP address is the IP of the requested resource. The destination port equals 80, except for cases when a direct HTTP proxy is configured in the client web browser.
Step 7.NAD intercepts client requests and prepares SYN-ACK packets with a source IP equal to the requested resource IP, destination IP equal to the client IP, and source port equal to 80.
Important considerations:
- NADs must have an HTTP server running on the port on which the client sends requests. By default, it is port 80. For catalyst switch http must be on
- If the client uses a direct HTTP proxy web server, the HTTP server must run on the proxy port on NAS. This scenario is outside of the scope of this document.
- In the cases when NAD does not have a local IP address in the client subnet SYN-ACK is sent with NAD routing table (over management interface usually).
In this scenario, the packet is routed over L3 infrastructure and must be routed back toward the client by an L3 upstream device.
If the L3 device is a stateful firewall, an additional exception must be given for such asymmetric routing.
Step 8. Client finishes TCP three-way handshake by ACK.
Step 9. HTTP GET for the target resource is sent by a client.
Step 10. NAD returns a redirect URL to the client with HTTP code 302 (page moved), on some NADs redirect can be returned inside of the HTTP 200 OK message in the location header.
before we proceed below, keep in mind that this section only happens when there is no client detected on computer then redirect URL is for CCP portal and this whole process is only to push Network Setup Assistant from CCP portal to probe the admin portal on port 8905 in order to download the Anyconnect client securely over SSL, if anyconnect client is already provisioned then we can skip directly to “Step 19.Anyconnect ISE posture process is launched.”
Step 11. The client sends a DNS request for the FQDN from the redirect URL. FQDN must be resolvable on the DNS server side.
Step 12. SSL connection over port received in redirect URL is established (default 8443). This connection is protected by a portal certificate from the ISE side. Client Provisioning Portal (CPP) is presented to the user.
Step 13.Before you provide a download option to the client, ISE must pick the target client provisioning (CP) policy. The Operation System (OS) of the client detected from the Browser user-agent and other information required for CPP policy selection are retrieved from the authentication session (like AD/LDAP groups and so on). ISE knows the target session from the session id presented in the redirect URL.
Step 14. Network Setup Assistant (NSA) download link is returned to the client. The client downloads the application.
Note: Normally you can see NSA as part of BYOD flow for Windows and Android but as well this application can be used to install Anyconnect or its components from ISE.
Step 15.The user runs the NSA application.
Step 16. NSA sends the first discovery probe – HTTP /auth/discovery to the Default gateway. NSA expects redirect-url as a result.
Note: For connections over VPN on MAC OS devices this probe is ignored as MAC OS does not have a default gateway on the VPN adapter.
Step 17.NSA sends a second probe if the first one fails. The second probe is an HTTP GET /auth/discovery to enroll.cisco.com. This FQDN must be successfully resolvable by the DNS server. In a VPN scenario with a split tunnel, traffic to enroll.cisco.com must be routed through the tunnel.
Step 18. If any of the (HTTP) probes succeed, NSA establishes an SSL connection over port 8905 with information obtained from redirect-url. This connection is protected by the ISE admin certificate. Inside this connection NSA downloads Anyconnect.
Important considerations:
- Prior to ISE 2.2 release, SSL communication over port 8905 is a requirement for posture.
- To avoid certificate warnings both portal and admin certificates must be trusted on the client side.
- In multi-interface ISE deployments interfaces other than G0 can be bound to FQDN differently from system FQDN (with the use of
ip hostCLI command). This can cause problems with Subject Name(SN)/Subject Alternative Name (SAN) validation. If the client is redirected to FQDN from interface G1, for example, the system FQDN can differ from the FQDN in the redirect URL for the 8905 communication certificate. As a solution for this scenario, you can add FQDNs of additional interfaces in admin certificate SAN fields, or you can use a wildcard in the admin certificate.
Step 19.Anyconnect ISE posture process is launched.
Anyconnect ISE Posture module starts in any of these situations:
- After installation
- After the default gateway value change
- After the system user login event
- After the system power event
Step 20. At this stage, Anyconnect ISE Posture Module initiates policy server detection. This is accomplished with a series of probes that are sent at the same time (as opposed to Network Setup Assistant that probes one by one) by the Anyconnect ISE Posture module.
for all these probes, aim is to get a URL redirect, just like user’s browser launch caused URL redirect (if no anyconnect client then Network Setup Assistant got redirect from HTTP probes)
- Probe 1 – HTTP get /auth/discovery to default gateway IP [http://10.114.250.1/auth/discovery/]. Consider that MAC OS devices do not have a default gateway on the VPN adapter. The expected result for the probe is redirect-url.
- Probe 2 – HTTP GET /auth/discovery to
enroll.cisco.com[http:enroll.cisco.com/auth/discovery/]. This FQDN needs to be successfully resolvable by the DNS server. In a VPN scenario with a split tunnel, traffic toenroll.cisco.commust be routed through the tunnel. The expected result for the probe is redirect-url. - Probe 3 – HTTP get /auth/discovery to discovery host. The Discovery host value is returned from ISE during installation in the AC posture profile. The expected result for the probe is redirect-url.
- Probe 4 – HTTP GET /auth/status over SSL on port 8905 to previously connected PSN (from xml profile , no redirect is required as this is direct connection to last PSN). This request contains information about client IPs and MACs list for session lookup on the ISE side. This is not presented during the first posture attempt. “Connection is protected by an ISE admin certificate“. As a result of this probe, ISE can return the session ID back to the client if the node where the probe landed is the same node where the user has been authenticated.
Note: As a result of this probe, posture can be done successfully even without working redirection under some circumstances. Successful posture without redirection requires that the current PSN which authenticated the session must be the same as the previously successfully connected PSN. Keep in mind that prior to ISE 2.2, successful posture without redirection is more of an exception rather than a rule.
The next steps describe the posture process in the case when the redirect URL is received (flow marked with letter a) as a result of one of the probes.
Step 21. Anyconnect ISE Posture module / client establishes a connection to the client provisioning portal with the use of a URL retrieved during the discovery phase. At this stage, ISE makes client provisioning policy validation once again with the use of the information from the authenticated sessions (since we are still building on top of original 802.1x (so no body can dial this URL and download AC configuration, AC updates, Posture module) and we need get to the posture state “Compliant” or “non Compliant”) and user agent which anyconnect client.
Step 22.If client provisioning policy is detected, ISE returns redirect to port 8905.
Step 23. Agent establishes a connection to ISE over port 8905. During this connection, ISE returns URLs for the posture profile, compliance module, and anyconnect updates to download.
Step 24.AC ISE Posture module configuration download from ISE.
Step 25.Updates download and installation if required.
Step 26. AC ISE Posture module collects initial information about the system (like OS version, installed security products, and their definition version).
Step 26.a. At this stage, the AC ISE posture module involves OPSWAT API to collect information about security products. The collected data is sent to ISE.
Step 26.b. As a reply to this request, ISE provides a posture requirements list. The requirements list is selected as a result of posture policy processing. To match the correct policy, ISE uses the device OS version (present in the request) and session id value to pick other required attributes (AD/LDAP groups). The session ID value is sent by the client as well.
Step 27. At this step, the client involves OPSWAT calls and other mechanisms to check posture requirements. The final report with the requirements list and their status are sent to ISE. ISE needs to make the final decision about the endpoint compliance status. If the endpoint is marked as non-compliant at this step, a set of remediation actions is returned. For the compliant endpoint, ISE writes compliance status into the session and as well puts the last posture timestamp to the endpoint attributes if Posture Lease is configured. The posture result is sent back to the endpoint. In the case of Posture Reassessment (PRA) time for PRA is put by ISE into this packet as well.
In a non-compliant scenario take these points into account:
- Some remediation actions (like display text messages, link remediation, file remediation, and others) are executed by the posture agent itself.
- Other remediation types (like AV. AS, WSUS, and SCCM) require OPSWAT API communication between the posture agent and the target product. In this scenario posture agent just sends a remediation request to the product. Remediation itself is done by the security products directly.
Note: In case when security product has to communicate with external resources (Internal/External Update servers) such as Antivirus Product Installed on Laptop, you must ensure that this communication is allowed in Redirect-ACL/DACL.
Step 28. ISE sends a COA request to the NAD which must trigger a new authentication for the user. NAD must confirm this request by COA ACK. Keep in mind that for the VPN cases COA push is used, so no new authentication request is sent. Instead, ASA removes previous authorization parameters (redirect URL, redirect ACL, and DACL) from the session and applies new parameters from the COA request.
Step 29. New authentication request for the user.
Important considerations:
- Typically for Cisco NAD COA, reauth is used by ISE, and this instructs NAD to initiate a new authentication request with the previous session ID.
- On the ISE side, the same session ID value is an indication that previously collected session attributes must be reused (complaint status in our case) and a new authorization profile based on those attributes must be assigned.
- In case of a session ID change, this connection is treated as new, and the full posture process is restarted.
- In order to avoid re-posture at each session id change, a posture lease can be used. In this scenario, information about the posture status is stored in the endpoint attributes which stays on the ISE even if the session ID gets changed.
Step 30. A new authorization policy is selected on the ISE side based on posture status.
Step 31. Access-Accept with new authorization attributes is sent to the NAD.
The next flow describes the scenario when the redirect URL is not retrieved (marked with letter b) by any posture probe and the previously connected PSN has been queried by the last probe. All steps here are exactly the same as in the case with redirect URL except the replay which is returned by PSN as a result of Probe 4. If this probe landed on the same PSN which is an owner for the current authentication session, the replay contains the session id value which is later used by the posture agent to finish the process. In case when previously connected headend is not the same as the current session owner, session lookup fails and an empty response is returned to the AC ISE posture module. As an ultimate result of this, the No Policy Server Detected message is returned to the end user.
In Diagram above if probe 4 is successful because of last succesful connection to PSN (as none of the Probes worked), direct connection (without redirect) to last PSN from xml file is established on port 8905 over SSL, Anyconnect client sends IP and MAC over SSL so PSN can lookup existing session exactly like we analyst lookup existing session during troubleshooting
Posture Flow Post ISE 2.2
ISE 2.2 and newer versions support both redirection and redirectionless flows simultaneously. This is the detailed explanation for redirectionless posture flow:
Step 1.Authentication is the first step of the flow. It can be dot1x, MAB, or VPN.
Step 2.ISE has to choose the authentication and authorization policy for the user. In posture, the scenario chosen authorization policy must contain a reference to the posture status, which initially must be either unknown or not applicable. To cover both these cases, conditions with posture status unequal compliance can be used. For a posture with no redirection, there is no need to use any Web Redirection configuration in the authorization profile. You can still consider the use of a DACL or Airspace ACL to limit user access at the stage when posture status is not available.
Step 3.ISE returns Access-Accept with authorization attributes.
Step 4. If the DACL name is returned in Access-Accept, NAD initiates DACL content download and applies the authorization profile to the session after it is obtained.
Step 5. The new approach assumes that redirection is not possible, so the user must enter the client provisioning portal FQDN manually. FQDN of the CPP portal must be defined in the portal configuration on the ISE side. From the DNS server perspective, A-record must point to the ISE server with the PSN role enabled.
Step 6. The client sends HTTP to get to the client provisioning portal FQDN, this request is parsed on the ISE side and the full portal URL is returned back to the client.
Step 7.SSL connection over port received in redirect URL is established (default 8443). This connection is protected by a portal certificate from the ISE side. The Client Provisioning Portal (CPP) is presented to the user.
Step 8. At this step two events occur on ISE:
- Single Sign On (SSO) – ISE attempts to look up previous successful authentication. ISE uses the source IP address from the packet as a search filter for live radius sessions.
Note: Session is retrieved based on a match between the source IP in the packet and Framed IP address in the session. The framed IP address is normally retrieved by ISE from the interim accounting updates, so it is required to have accounting enabled on the NAD side. Also, you must remember that SSO is only possible on the node which owns the session. If, for example, the session is authenticated on PSN 1, but the FQDN itself points to PSN2, the SSO mechanism fails.
- Client provisioning policy lookup – in case of a successful SSO, ISE can use data from authenticated session and User-agent from the client browser. In case of an unsuccessful SSO, the user must provide credentials and after user authentication information is retrieved from Internal and External Identity stores (AD/LDAP/Internal groups), it can be used for client provisioning policy check.
Note: Due to the Cisco bug ID CSCvd11574, you can see an error at the time of client provisioning policy selection for the non-SSO cases when the external user is a member of multiple AD/LDAP groups added in external identity store configuration. The mentioned defect is fixed that starts from ISE 2.3 FCS and the fix requires to use of CONTAINS in condition with AD group instead of EQUAL.
Step 9. After the client provisioning policy selection, ISE displays the agent download URL to the user. After you click on download NSA, the application is pushed to the user. NSA filename contains the FQDN of the CPP portal.
Step 10.At this step, NSA runs probes to establish a connection to the ISE. Two probes are classic ones, and the third one is designed to allow ISE discovery in environments without url redirection.
- NSA sends the first discovery probe – HTTP /auth/discovery to the Default gateway. NSA expects redirect-url as a result.
- NSA sends a second probe if the first one fails. The second probe is an HTTP GET /auth/discovery to
enroll.cisco.com. This FQDN must be successfully resolvable by the DNS server. In a VPN scenario with a split tunnel, traffic toenroll.cisco.commust be routed through the tunnel. - NSA sends the third probe over the CPP portal port to the client provisioning portal FQDN. This request contains information about the portal session-id which allows ISE to identify which resources have to be provided.
Step 11. NSA downloads Anyconnect and/or specific modules. The download process is done over the client provisioning portal port.
Step 12. In ISE 2.2, the posture process is divided into two stages. The first stage contains a set of traditional posture discovery probes to support backward compatibility with deployments that rely on the url redirect.
Step 13. The first stage contains all traditional posture discovery probes. To get more details about the probes, review Step 20. in the pre-ISE 2.2 posture flow.
Step 14.Stage two contains two discovery probes that allow the AC ISE posture module to establish a connection to the PSN where the session is authenticated in environments where redirection is not supported. During stage two, all probes are sequential.
- Probe 1 – During the first probe, the AC ISE posture module tries to establish with IP/FQDNs from the ‘Call Home List’. A list of the targets for the probe must be configured in the AC posture profile on the ISE side. You can define IPs/FQDNs separated by commas, with a colon you can define the port number for each Call Home destination. This port must be equal to the port on which the client provisioning portal run. On the client side information about call home servers is located in
ISEPostureCFG.xml, this file can be found in the folder –C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\.
In case the call home target does not own the session, a lookup for the owner is needed at this stage. AC ISE Posture module instructs ISE to start owner lookup with the use of a special target URL –/auth/ng-discoveryrequest. It also contains the client IPs and MACs list. After this message is received by the PSN session, a lookup is first done locally (this lookup uses both IPs and MACs from the request sent by the AC ISE posture module). If the session is not found, PSN initiates an MNT node query. This request contains only the MACs list, as a result, the FQDN of the owner must be obtained from the MNT. After this, PSN returns owners FQDN back to the client. The next request from the client is sent to session owner FQDN with auth/status in URL and list of IPs and MACs. - Probe 2 – At this stage, the AC ISE posture module tries PSN FQDNs which are located in
ConnectionData.xml. You can find this file inC:\Users\<current user>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\. AC ISE Posture module creates this file after the first posture attempt. The file contains a list of ISE PSNs FQDNs. The content of the list can be dynamically updated during the next connection attempts. The end goal of this probe is to get the FQDN of the current session owner. Implementation is identical to Probe 1. with the only difference in probe destination selection.
The file itself is located in the folder of the current user in case the device is used by multiple users. Different user is not able to use information from this file. This can lead users to the chicken and egg problem in environments without redirection when Call home targets are not specified.
Step 15. After information about the session owner is obtained, all subsequent steps are identical to the pre-ISE 2.2 flow.
Configure
For this document, ASAv is used as a network access device. All tests are conducted with posture over VPN. ASA configuration for posture over VPN support is outside of the scope of the document. For more details refer to ASA Version 9.2.1 VPN Posture with ISE Configuration Example.
Note: For Deployment with VPN users, the recommended setting is redirection-based posture. Configuration of callhomelist is not recommended. For all non-vpn-based users, ensure DACL is applied such that they do not talk to PSN where posture is configured.
Network Diagram
This topology is used in tests. With ASA, it is possible to easily simulate the scenario when the SSO mechanism for the Client Provisioning portal fails on the PSN side, because of the NAT feature. In the case of regular posture flow over VPN, SSO must work fine since NAT is normally not enforced for VPN IPs when users enter the corporate network.
Configurations
Client Provisioning Configuration
These are the steps to prepare the Anyconnect configuration.
Step 1. Anyconnect package download. Anyconnect package itself is not available for direct download from ISE so before you begin, ensure that AC is available on your PC. This link can be used for AC download – https://www.cisco.com/site/us/en/products/security/secure-client/index.html. In this document, anyconnect-win-4.4.00243-webdeploy-k9.pkg package is used.
Step 2. In order to upload the AC package to ISE, navigate to Policy > Policy Elements > Results > Client Provisioning > Resourcesand click Add. Choose Agent resources from the local disk. In the new window, choose Cisco Provided Packages, click browse and choose the AC package on your PC.
Click Submit to finish the import.
Step 3. The compliance module must be uploaded to ISE. On the same page, click Add and choose the Agent resources from Cisco site. In the resource list, you must check a compliance module. For this document, the AnyConnectComplianceModuleWindows 4.2.508.0 compliance module is used.
Step 4. Now AC posture profile must be created. Click Add and choose the NAC agent or Anyconnect posture profile.
- Choose the type of profile. AnyConnect must be used for this scenario.
- Specify profile name. Navigate to the
Posture Protocolsection of the profile.
- Specify the
Server Name Rules, this field cannot be empty. The field can contain FQDN with wildcard which restricts AC ISE posture module connection to PSNs from the appropriate namespace. Put a star if any FQDN must be allowed. - Names and IPs specified here are in use during stage 2 of posture discovery. You can separate names by coma as well port numbers can be added after FQDN/IP with the use of the colon. In case the AC deployed out-of-band (not from the ISE client provisioning portal) with the use of the GPO or any other software provisioning system presence of Call Home addresses become essential since this is only one probe that can reach ISE PSN successfully. This means that in the case of Out-Of-Band AC provisioning, the administrator must create an AC ISE posture profile with the use of the AC profile editor and provision this file along with AC installation.
Note: Keep in mind that the presence of Call home addresses is critical for multiuser PCs. Review Step 14. in Posture flow post-ISE 2.2.
Step 5.Create AC configuration. Navigate to Policy > Policy Elements > Results > Client Provisioning > Resources, click Add, then choose AnyConnect Configuration.
- Choose the AC package.
- Provide AC configuration name.
- Choose the compliance module version.
- Choose the AC posture configuration profile from the drop-down list.
Step 6. Configure client provisioning policy. Navigate to Policy > Client Provisioning. In the case of the initial configuration, you can fill empty values in the policy presented with defaults. If you need to add a policy to the posture configuration that exists, navigate to the policy that can be reused and choose Duplicate Above or Duplicate Below . A brand-new policy can also be created.
This is an example of the policy used in the document.
Choose your AC configuration in the result section. Keep in mind, that in case of SSO failure ISE can have only attributes from login to portal. These attributes are limited to information that can be retrieved about users from internal and external identity stores. In this document, the AD group is used as a condition in the Client Provisioning policy.
Posture Policies and Conditions
A simple posture check is used. ISE is configured to check the status of the Window Defender service on the end device side. Real-life scenarios can be much more complicated but general configuration steps are the same.
Step 1. Create posture condition. Posture conditions are located in Policy > Policy Elements > Conditions > Posture. Choose the type of posture condition. Here is an example of a Service condition that must check if the Windows Defender service is running.
Step 2.Posture requirements configuration. Navigate to Policy > Policy Elements > Results > Posture > Requirements. This is an example of a Window Defender check:
Choose your posture condition in the new requirement and specify remediation action.
Step 3. Posture policy configuration. Navigate to Policy > Posture. Here, you can find an example of the policy used for this document. The policy has Windows Defender requirement assigned as mandatory and only contains external AD group name as a condition.
Configure the Client Provisioning Portal
For posture without redirection, the configuration of the client provisioning portal must be edited. Navigate to Administration > Device Portal Management > Client Provisioning.You can either use the default portal or create your own. The same portal can be used for both postures with and without redirection.
These settings must be edited in the portal configuration for the non-redirection scenario:
- In Authentication, specify Identity Source Sequence that must be used if SSO cannot locate a session for the user.
- As per the selected Identity Source Sequence list of available groups is populated. At this point, you must select groups that are authorized for portal login.
- FQDN of the client provisioning portal must be specified for scenarios when AC needs to be deployed from the client provisioning portal. This FQDN must be resolvable to ISE PSNs IPs. Users must be instructed to specify the FQDN in the web browser during the first connection attempt.
Configure Authorization Profiles and Policies
Initial access for clients when posture status is not available must be restricted. This can be achieved in multiple ways:
- DACL Assignment – During the restricted access phase, DACL can be assigned to the user to limit access. This approach can be used for Cisco Network Access Devices.
- VLAN Assignment – Before successful posture users can be put in restricted VLAN, this approach must work fine for almost any NAD vendor.
- Radius Filter-Id – With this attribute, ACL locally defined on NAD can be assigned to the user with unknown posture status. As this is a standard RFC attribute, this approach must work well for all NAD vendors.
Step 1. Configure DACL. Since this example is based on ASA, a NAD DACL can be used. For real-life scenarios, you must consider VLAN or Filter-ID as possible options.
In order to create DACL, navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLsand click Add.
During the unknown posture state, at least these permissions must be provided:
- DNS traffic
- DHCP traffic
- Traffic to ISE PSNs (ports 80 and 443 for a possibility to open friendly FQDN of portal. Port on which CP portal is running is 8443 by default and port 8905 for backward compatibility)
- Traffic to remediation servers if needed
This is an example of DACL without remediation servers:
Step 2. Configure authorization profile.
As usual for posture two authorization profiles are required. The first one must contain any kind of network access restrictions (profile with DACL used in this example). This profile can be applied to the authentications for which posture status is not equal to compliant. The second authorization profile can contain just permit access and can be applied for sessions with posture status equal to compliance.
To create an authorization profile navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.
Example of the restricted access profile:
In this example, the default ISE profile PermitAccess is used for the session after a successful posture status check.
Step 3. Configure authorization policy. During this step, two authorization policies must be created. One is to match the initial authentication request with unknown posture status and the second one is to assign full access after a successful posture process.
This is an example of simple authorization policies for this case:
Configuration of Authentication policy is not a part of this document but you must keep in mind that before authorization policy processing successful authentication must happen.
Verify
Basic verification of the flow can consist of three main steps:
Step 1. Authentication flow verification.
- Initial authentication. For this step, you can be interested in the validation of which the authorization profile has been applied. If an unexpected authorization profile has been applied, investigate a detailed authentication report. You can open this report with a click on the magnifying glass in the Details column. You can compare attributes in detailed authentication reports with conditions in the authorization policy which you expect to match.
- DACL download event. This string is presented only in the case when the authorization profile selected for the initial authentication contains a DACL name.
- Portal authentication – This step in the flow indicates that the SSO mechanism failed to locate the user session. This can happen due to multiple reasons:
- NAD is not configured to send accounting messages or Framed IP address is not present in them
- CPP portal FQDN has been resolved to the IP of the ISE node different from the node where the initial authentication has been processed
- The client is located behind the NAT
- Session data change. In this particular example, the session state has changed from Unknown to Compliant.
- COA to the network access device. This COA must be successful to push new authentication from the NAD side and new authorization policy assignments on the ISE side. If COA has failed, you can open a detailed report to investigate the reason. The most common issues with COA can be:
- COA timeout – In such case either the PSN which has sent the request is not configured as a COA client on the NAD side, or the COA request has been dropped somewhere on the way.
- COA negative ACK – Indicate that COA has been received by NAD but due to some reason COA operation cannot be confirmed. For this scenario, a detailed report must contain a more detailed explanation.
As ASA is used as a NAD for this example, you can see no subsequent authentication request for the user. This happens due to the fact ISE uses COA push for ASA which avoids VPN service interruption. In such a scenario, COA itself contains new authorization parameters, so reauthentication is not needed.
Step 2.Client provisioning policy selection verification – For this, you can run a report on ISE which can help you to understand which client provisioning policies were applied for the user.
Navigate to Operations > Reports Endpoint and Users > Client Provisioning and run the report for the date which you need.
With this report, you can verify what client provisioning policy was selected. Also, in case of failure, reasons must be presented in the Failure Reason column.
Step 3.Posture report verification – Navigate to Operations > Reports Endpoint and Users > Posture Assessment by Endpoint.
You can open a detailed report from here for each particular event to check, for example, to which session ID this report belongs, which exact posture requirements were selected by ISE for the endpoint and the status for each requirement.
Troubleshoot
General Information
For posture process troubleshooting, these ISE components must be enabled to debug on the ISE nodes where the posture process can happen:
client-webapp– The component responsible for agent provisioning. Target log filesguest.logandise-psc.log.guestacess– The component responsible for client provisioning portal component and session owner lookup (when the request comes to the wrong PSN). Target log file –guest.log.provisioning– The component responsible for client provisioning policy processing. Target log file –guest.log.posture– All posture-related events. Target log file –ise-psc.log.
For client-side troubleshooting, you can use these:
acisensa.log-In case of client provisioning failure on the client side, this file is created in the same folder to which NSA has been downloaded (downloads directory for Windows normally).AnyConnect_ISEPosture.txt– This file can be found in the DART bundle in the directoryCisco AnyConnect ISE Posture Module. All information about ISE PSN discovery and general steps of posture flow is logged into this file.
Troubleshooting Common Problems
SSO Related Issues
In case of a successful SSO, you can see these messages in the ise-psc.log, this set of messages indicates that session lookup has finished successfully and authentication on the portal can be skipped.
2016-11-09 15:07:35,951 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.121], mac Addrs [null]
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010002600058232bb8 using ipAddr 10.62.145.121
You can use the endpoint IP address as a search key to find this information.
A bit later in the guest log, you must see that authentication has been skipped:
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- SessionInfo is not null and session AUTH_STATUS = 1
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key and value: Radius.Session c0a801010002600058232bb8
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key : Radius.Session
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- Login step will be skipped, as the session =c0a801010002600058232bb8 already established for mac address null , clientIPAddress 10.62.145.121
2016-11-09 15:07:36,066 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cpm.guestaccess.flowmanager.processor.PortalFlowProcessor -::- After executeStepAction(INIT), returned Enum: SKIP_LOGIN_PROCEED
In case the SSO does not work, the ise-psc log file contains information about session lookup failure:
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.44
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.44], mac Addrs [null]
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.44
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = null
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType == null or is not a virtual NAS_PORT_TYPE ( 5 ).
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- No Radius session found
In the guest.log in such a case, you must see full user authentication on the portal:
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Find Next Step=LOGIN
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Step : LOGIN will be visible!
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Returning next step =LOGIN
2017-02-23 17:59:00,780 INFO [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Radius Session ID is not set, assuming in dry-run mode
In case of authentication failures on the portal, you must focus on the portal configuration verification – Which identity store is in use? Which groups are authorized for login?
Troubleshoot Client Provisioning Policy Selection
In case of client provisioning policies failures or incorrect policy processing, you can check the guest.log file for more details:
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- In Client Prov : userAgent =Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0, radiusSessionID=null, idGroupName=S-1-5-21-70538695-790656579-4293929702-513, userName=user1, isInUnitTestMode=false
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- UserAgent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- Client OS: Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Retrieved OS=Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Updating the idGroupName to NAC Group:NAC:IdentityGroups:S-1-5-21-70538695-790656579-4293929702-513
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- User Agent/Radius Session is empty or in UnitTestMode
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Calling getMatchedPolicyWithNoRedirection for user=user1
2017-02-23 17:59:07,505 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- CP Policy Status =SUCCESS, needToDoVlan=false, CoaAction=NO_COA
In the first string, you can see how information about the session is injected into the policy selection engine, in case of no policy match or incorrect policy match, you can compare attributes from here with your client provisioning policy configuration. The last string indicates the policy selection status.
Troubleshoot Posture Process
On the client side, you must be interested in the investigation of the probes and their results. This is an example of a successful stage 1 probe:
******************************************
Date : 02/23/2017
Time : 17:59:57
Type : Unknown
Source : acise
Description : Function: Target::Probe
Thread Id: 0x4F8
File: SwiftHttpRunner.cpp
Line: 1415
Level: debug
PSN probe skuchere-ise22-cpp.example.com with path /auth/status, status is -1..
******************************************
At this stage, PSN returns to AC information about the session owner. You can see these couple of messages later:
******************************************
Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise
Description : Function: Target::probeRecentConnectedHeadEnd
Thread Id: 0xBE4
File: SwiftHttpRunner.cpp
Line: 1674
Level: debug
Target skuchere-ise22-2.example.com, posture status is Unknown..
******************************************
Session owners return to the agent all the required information:
******************************************
Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise
Description : Function: SwiftHttpRunner::invokePosture
Thread Id: 0xFCC
File: SwiftHttpRunner.cpp
Line: 1339
Level: debug
MSG_NS_SWISS_NEW_SESSION, <?xml version="1.0" ?>
<root>
<IP></IP>
<FQDN>skuchere-ise22-2.example.com</FQDN>
<PostureDomain>posture_domain</PostureDomain>
<sessionId>c0a801010009e00058af0f7b</sessionId>
<configUri>/auth/anyconnect?uuid=106a93c0-9f71-471c-ac6c-a2f935d51a36</configUri>
<AcPackUri>/auth/provisioning/download/81d12d4b-ff58-41a3-84db-5d7c73d08304</AcPackUri>
<AcPackPort>8443</AcPackPort>
<AcPackVer>4.4.243.0</AcPackVer>
<PostureStatus>Unknown</PostureStatus>
<PosturePort>8443</PosturePort>
<PosturePath>/auth/perfigo_validate.jsp</PosturePath>
<PRAConfig>0</PRAConfig>
<StatusPath>/auth/status</StatusPath>
<BackupServers>skuchere-ise22-1.example.com,skuchere-ise22-3.example.com</BackupServers>
</root>
.
******************************************
From the PSN side, you can focus on these messages in the guest.log when you expect the initial request that comes to the node does not own the session:
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Got http request from 10.62.145.44 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243)
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- mac_list from http request ==> 00:0B:7F:D0:F8:F4,00:0B:7F:D0:F8:F4
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- iplist from http request ==> 172.16.31.12,10.62.145.95
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session id from http request - req.getParameter(sessionId) ==> null
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 172.16.31.12
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 10.62.145.95
2017-02-23 17:59:56,368 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Found Client IP null and corresponding mac address null
2017-02-23 17:59:56,369 ERROR [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Session Info is null
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Not able to find a session for input values - sessionId : null, Mac addresses : [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4], client Ip : [172.16.31.12, 10.62.145.95]
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- clientMac is null/ empty, will go over the mac list to query MNT for active session
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performing MNT look up for macAddress ==> 00-0B-7F-D0-F8-F4
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performed MNT lookup, found session 0 with session id c0a801010009e00058af0f7b
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting NIC name for skuchere-ise22-cpp.example.com
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- local interface 0 addr 10.48.17.249 name eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Nic name for local host: skuchere-ise22-cpp.example.com is: eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting host FQDN or IP for host skuchere-ise22-2 NIC name eth0
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- hostFQDNOrIP for host skuchere-ise22-2 nic eth0 is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- PDP with session of 00-0B-7F-D0-F8-F4 is skuchere-ise22-2, FQDN/IP is: skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Redirecting the request to new URL: https://skuchere-ise22-2.example.com:8443/auth/status
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session info is null. Sent an http response to 10.62.145.44.
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP-WITH-SESSION value is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header Location value is https://skuchere-ise22-2.example.com:8443/auth/status
Here you can see that PSN first tries to find a session locally, and after failure initiates a request to MNT with the use of the IPs and MACs list to locate the session owner.
A little bit later you must see a request from the client on the correct PSN:
2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [172.16.31.12, 10.62.145.95], mac Addrs [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4]
2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 172.16.31.12
2017-02-23 17:59:56,791 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 172.16.31.12
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010009e00058af0f7b using ipAddr 172.16.31.12
As a next step, PSN performs client provisioning policy lookup for this session:
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHostNameBySession()
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: c0a801010009e00058af0f7b, MacAddr: 00-0b-7f-d0-f8-f4, ipAddr: 172.16.31.12
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: c0a801010009e00058af0f7b, IP addrs: [172.16.31.12], mac Addrs [00-0b-7f-d0-f8-f4]
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session using sessionId c0a801010009e00058af0f7b
2017-02-23 17:59:56,795 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -::::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 17:59:58,203 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHPortNumberBySession()
2017-02-23 17:59:58,907 DEBUG [http-bio-10.48.30.41-8443-exec-10][] cisco.cpm.posture.util.AgentUtil -::::- Increase MnT counter at CP:ClientProvisioning.ProvisionedResource.AC-44-Posture
In the next step, you can see the process of posture requirements selection. At the end of the step, a list of requirements is prepared and returned to the agent:
2017-02-23 18:00:00,372 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- About to query posture policy for user user1 with endpoint mac 00-0b-7f-d0-f8-f4
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- agentCMVersion=4.2.508.0, agentType=AnyConnect Posture Agent, groupName=OESIS_V4_Agents -> found agent group with displayName=4.x or later
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- About to retrieve posture policy resources for os 7 Professional, agent group 4.x or later and identity groups [NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation, NAC Group:NAC:IdentityGroups:Any]
2017-02-23 18:00:00,432 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by agent group with FQN NAC Group:NAC:AgentGroupRoot:ALL:OESIS_V4_Agents
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by agent group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by OS group with FQN NAC Group:NAC:OsGroupRoot:ALL:WINDOWS_ALL:WINDOWS_7_ALL:WINDOWS_7_PROFESSIONAL_ALL
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- stealth mode is 0
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by os group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by Stealth mode NSF group with FQN NAC Group:NAC:StealthModeStandard
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Procesing obligation with posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id urn:cisco:cepm:3.3:xacml:response-qualifier for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id PostureReqs for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Posture policy resource id WinDefend has following associated requirements []
2017-02-23 18:00:03,884 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- policy enforcemnt is 0
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- simple condition: [Name=WinDefend, Descriptionnull, Service Name=WinDefend, Service Operator=Running, Operating Systems=[Windows All], Service Type=Daemon, Exit code=0]
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- check type is Service
2017-02-23 18:00:04,069 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- NAC agent xml <?xml version="1.0" encoding="UTF-8"?><cleanmachines>
<version>ISE: 2.2.0.470</version>
<encryption>0</encryption>
<package>
<id>10</id>
<name>WinDefend</name>
<description>Enable WinDefend</description>
<version/>
<type>3</type>
<optional>0</optional>
<action>3</action>
<check>
<id>WinDefend</id>
<category>3</category>
<type>301</type>
<param>WinDefend</param>
<operation>running</operation>
</check>
<criteria>(WinDefend)</criteria>
</package>
</cleanmachines>
Later, you can see that the posture report was received by PSN:
2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- UDID is 8afb76ad11e60531de1d3e7d2345dbba5f11a96d for end point 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- Received posture request [parameters: reqtype=report, userip=10.62.145.44, clientmac=00-0b-7f-d0-f8-f4, os=WINDOWS, osVerison=1.2.1.6.1.48, architecture=9, provider=Device Filter, state=, userAgent=Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243), session_id=c0a801010009e00058af0f7b
At the end of the flow, ISE marks the endpoint as compliant and initiates COA:
2017-02-23 18:00:04,272 INFO [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- Posture state is compliant for endpoint with mac 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- entering triggerPostureCoA for session c0a801010009e00058af0f7b
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b]
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture status for session id c0a801010009e00058af0f7b is Compliant
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Issue CoA on active session with sessionID c0a801010009e00058af0f7b
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b]