Showing posts with label BGP. Show all posts
Showing posts with label BGP. Show all posts
Saturday, May 7, 2011
Monday, March 28, 2011
BGP Update Generation - Part 2
Traditional peer-groups were introduced to improve CPU utilization, and make configuration less redundant and easy to read. However, the way peer-groups work, the common attributes must be replicated across peer-groups. Hence, redundant configuration is not completely avoided and the ability to have session-specific configuration is limited.
The BGP dynamic peer-group feature identifies peers that have same outbound policy and optimizes update generation and replication across those peers. Dynamic peer-groups separate the peer-group configuration from update-replication through two features-
Peer Templates
Update groups
Peer Templates
The configuration feature of peer templates allows a set of configuration options to be applied to a set of neighbors. Peer templates are reusable and support inheritance. There are two types of peer templates-
Peer session templates
Peer policy templates
Peer session templates are used to build a template of general session configuration. It does not include any policy-type attributes. It can be configured as below and supports these commands-
Peer session template
Edge-1(config)# router bgp 100
Edge-1(config-router)# template ?
peer-policy Template configuration for policy parameters
peer-session Template configuration for session parameters
Edge-1(config-router)# template peer-session ?
WORD Name of peer-session template
Edge-1(config-router)# template peer-session GENERAL_SESSION
Edge-1(config-router-stmp)#?
BGP peer-policy configuration commands:
allowas-in Accept as-path with my AS present in it
default Set a command to its defaults
description Neighbor specific description
disable-connected-check One-hop away EBGP peer using loopback address
ebgp-multihop Allow EBGP neighbors not on directly connected
networks
exit-peer-session Exit from template configuration mode
fall-over session fall on peer route lost
inherit Inherit a template
local-as Specify a local-as number
no Negate a command or set its defaults
password Set a password
remote-as Specify a BGP neighbor
shutdown Administratively shut down this neighbor
timers BGP per neighbor timers
translate-update Translate Update to MBGP format
transport Transport options
ttl-security BGP ttl security check
update-source Source of routing updates
version Set the BGP version to match a neighbor
Peer policy templates are used to build a template of policy information. This includes manipulating actual BGP prefix information, such as filtering, capabilities and route-reflection. Peer policy template is configured as follows and support these commands-
Peer policy template
Edge-1(config)# router bgp 100
Edge-1(config-router)# template peer-policy GENERAL_POLICY
Edge-1(config-router-ptmp)#?
BGP peer-policy configuration commands:
advertisement-interval Minimum interval between sending BGP routing updates
allowas-in Accept as-path with my AS present in it
as-override Override matching AS-number while sending update
capability Advertise capability to the peer
default Set a command to its defaults
default-originate Originate default route to this neighbor
distribute-list Filter updates to/from this neighbor
dmzlink-bw Propagate the DMZ link bandwidth
exit-peer-policy Exit from template configuration mode
filter-list Establish BGP filters
inherit Inherit a template
maximum-prefix Maximum number of prefixes accepted from this peer
next-hop-self Disable the next hop calculation for this neighbor
next-hop-unchanged Propagate the iBGP paths's next hop unchanged for
this neighbor
no Negate a command or set its defaults
prefix-list Filter updates to/from this neighbor
remove-private-as Remove private AS number from outbound updates
route-map Apply route map to neighbor
route-reflector-client Configure a neighbor as Route Reflector client
send-community Send Community attribute to this neighbor
soft-reconfiguration Per neighbor soft reconfiguration
unsuppress-map Route-map to selectively unsuppress suppressed routes
weight Set default weight for routes from this neighbor
Update groups:
Update groups handle update replication. The router builds update groups dynamically based on examining the outbound policy of the configured BGP sessions. BGP peers with same outbound policies are assigned to same update group. No configuration is required for this feature.
Network topology:
This example will demonstrate peer session and peer policy templates on Edge-1 router. Edge-1 router creates a GENERAL_SESSION peer-session template which includes password and version. Edge-1 router also creates an INTERNAL_SESSION peer-session template for iBGP peers which includes iBGP specific configuration and also inherit GENERAL_SESSION settings. And lastly, it creates an EXTERNAL_SESSION template for eBGP peers and inherit GENERAL_SESSION settings too.
NOTE: Any configuration at the neighbor level takes precedence over template settings.
peer session templates on Edge-1
router bgp 100
template peer-session GENERAL_SESSION
password cisco
version 4
exit-peer-session
!
template peer-session INTERNAL_SESSION
inherit peer-session GENERAL_SESSION
remote-as 100
update-source Loopback 0
timers 30 90
exit-peer-session
!
template peer-session EXTERNAL_SESSION
inherit peer-session GENERAL_SESSION
remote-as 200
exit-peer-session
!
neighbor 2.2.2.2 inherit peer-session INTERNAL_SESSION
neighbor 3.3.3.3 inherit peer-session INTERNAL_SESSION
neighbor 10.2.2.2 inherit peer-session EXTERNAL_SESSION
!
The show ip bgp replication command displays update replication statistics for update-groups. Core-1 and Core-2 routers are part of the same update-group.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 2 2 0/1000 6/0
2 1 10.2.2.2 1 0 0/100 6/0
The show ip bgp update-group command displays update-group statistics.
show ip bgp update-group
Edge-1# show ip bgp update-group
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 2, replicated 2
Number of NLRIs in the update sent: max 3, min 2
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
2.2.2.2 3.3.3.3
BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 3, min 3
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.2.2.2
Advertise only Default-route to Core-1:
Now, a condition arises that only default-route be advertised to Core-1 router while full BGP table be advertised to Core-2 router. Admittedly, this can be achieved through various ways, however, peer policy template is also one of the options.
peer policy template on Edge-1
router bgp 100
template peer-policy DEFAULT_ONLY
filter-list 20 out
default-originate
exit-peer-policy
neighbor 2.2.2.2 inherit peer-policy DEFAULT_ONLY
!
ip prefix-list 20 seq 5 deny 0.0.0.0/0 le 32
!
The show ip bgp replication command shows that Core-1 router is dynamically assigned to another update-group since its outbound policy changed.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 1 10.2.2.2 1 0 0/100 6/0
2 1 3.3.3.3 2 0 0/100 6/0
3 1 2.2.2.2 0 0 0/100 6/0
The show ip bgp update-group command also shows Core-1 router in a different update-group.
show ip bgp update-group
Edge-1# show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 3, min 3
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.2.2.2
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 2, replicated 0
Number of NLRIs in the update sent: max 3, min 2
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
3.3.3.3
BGP version 4 update-group 3, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Outgoing update AS path filter list is 20
Unconditional default-originate
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
2.2.2.2
The template settings can be viewed using show ip bgp template {peer-session | peer-policy} command.
The BGP dynamic peer-group feature identifies peers that have same outbound policy and optimizes update generation and replication across those peers. Dynamic peer-groups separate the peer-group configuration from update-replication through two features-
Peer Templates
Update groups
Peer Templates
The configuration feature of peer templates allows a set of configuration options to be applied to a set of neighbors. Peer templates are reusable and support inheritance. There are two types of peer templates-
Peer session templates
Peer policy templates
Peer session templates are used to build a template of general session configuration. It does not include any policy-type attributes. It can be configured as below and supports these commands-
Peer session template
Edge-1(config)# router bgp 100
Edge-1(config-router)# template ?
peer-policy Template configuration for policy parameters
peer-session Template configuration for session parameters
Edge-1(config-router)# template peer-session ?
WORD Name of peer-session template
Edge-1(config-router)# template peer-session GENERAL_SESSION
Edge-1(config-router-stmp)#?
BGP peer-policy configuration commands:
allowas-in Accept as-path with my AS present in it
default Set a command to its defaults
description Neighbor specific description
disable-connected-check One-hop away EBGP peer using loopback address
ebgp-multihop Allow EBGP neighbors not on directly connected
networks
exit-peer-session Exit from template configuration mode
fall-over session fall on peer route lost
inherit Inherit a template
local-as Specify a local-as number
no Negate a command or set its defaults
password Set a password
remote-as Specify a BGP neighbor
shutdown Administratively shut down this neighbor
timers BGP per neighbor timers
translate-update Translate Update to MBGP format
transport Transport options
ttl-security BGP ttl security check
update-source Source of routing updates
version Set the BGP version to match a neighbor
Peer policy templates are used to build a template of policy information. This includes manipulating actual BGP prefix information, such as filtering, capabilities and route-reflection. Peer policy template is configured as follows and support these commands-
Peer policy template
Edge-1(config)# router bgp 100
Edge-1(config-router)# template peer-policy GENERAL_POLICY
Edge-1(config-router-ptmp)#?
BGP peer-policy configuration commands:
advertisement-interval Minimum interval between sending BGP routing updates
allowas-in Accept as-path with my AS present in it
as-override Override matching AS-number while sending update
capability Advertise capability to the peer
default Set a command to its defaults
default-originate Originate default route to this neighbor
distribute-list Filter updates to/from this neighbor
dmzlink-bw Propagate the DMZ link bandwidth
exit-peer-policy Exit from template configuration mode
filter-list Establish BGP filters
inherit Inherit a template
maximum-prefix Maximum number of prefixes accepted from this peer
next-hop-self Disable the next hop calculation for this neighbor
next-hop-unchanged Propagate the iBGP paths's next hop unchanged for
this neighbor
no Negate a command or set its defaults
prefix-list Filter updates to/from this neighbor
remove-private-as Remove private AS number from outbound updates
route-map Apply route map to neighbor
route-reflector-client Configure a neighbor as Route Reflector client
send-community Send Community attribute to this neighbor
soft-reconfiguration Per neighbor soft reconfiguration
unsuppress-map Route-map to selectively unsuppress suppressed routes
weight Set default weight for routes from this neighbor
Update groups:
Update groups handle update replication. The router builds update groups dynamically based on examining the outbound policy of the configured BGP sessions. BGP peers with same outbound policies are assigned to same update group. No configuration is required for this feature.
Network topology:
This example will demonstrate peer session and peer policy templates on Edge-1 router. Edge-1 router creates a GENERAL_SESSION peer-session template which includes password and version. Edge-1 router also creates an INTERNAL_SESSION peer-session template for iBGP peers which includes iBGP specific configuration and also inherit GENERAL_SESSION settings. And lastly, it creates an EXTERNAL_SESSION template for eBGP peers and inherit GENERAL_SESSION settings too.
NOTE: Any configuration at the neighbor level takes precedence over template settings.
peer session templates on Edge-1
router bgp 100
template peer-session GENERAL_SESSION
password cisco
version 4
exit-peer-session
!
template peer-session INTERNAL_SESSION
inherit peer-session GENERAL_SESSION
remote-as 100
update-source Loopback 0
timers 30 90
exit-peer-session
!
template peer-session EXTERNAL_SESSION
inherit peer-session GENERAL_SESSION
remote-as 200
exit-peer-session
!
neighbor 2.2.2.2 inherit peer-session INTERNAL_SESSION
neighbor 3.3.3.3 inherit peer-session INTERNAL_SESSION
neighbor 10.2.2.2 inherit peer-session EXTERNAL_SESSION
!
The show ip bgp replication command displays update replication statistics for update-groups. Core-1 and Core-2 routers are part of the same update-group.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 2 2 0/1000 6/0
2 1 10.2.2.2 1 0 0/100 6/0
The show ip bgp update-group command displays update-group statistics.
show ip bgp update-group
Edge-1# show ip bgp update-group
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 2, replicated 2
Number of NLRIs in the update sent: max 3, min 2
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
2.2.2.2 3.3.3.3
BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 3, min 3
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.2.2.2
Advertise only Default-route to Core-1:
Now, a condition arises that only default-route be advertised to Core-1 router while full BGP table be advertised to Core-2 router. Admittedly, this can be achieved through various ways, however, peer policy template is also one of the options.
peer policy template on Edge-1
router bgp 100
template peer-policy DEFAULT_ONLY
filter-list 20 out
default-originate
exit-peer-policy
neighbor 2.2.2.2 inherit peer-policy DEFAULT_ONLY
!
ip prefix-list 20 seq 5 deny 0.0.0.0/0 le 32
!
The show ip bgp replication command shows that Core-1 router is dynamically assigned to another update-group since its outbound policy changed.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 1 10.2.2.2 1 0 0/100 6/0
2 1 3.3.3.3 2 0 0/100 6/0
3 1 2.2.2.2 0 0 0/100 6/0
The show ip bgp update-group command also shows Core-1 router in a different update-group.
show ip bgp update-group
Edge-1# show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 3, min 3
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.2.2.2
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Update messages formatted 2, replicated 0
Number of NLRIs in the update sent: max 3, min 2
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
3.3.3.3
BGP version 4 update-group 3, internal, Address Family: IPv4 Unicast
BGP Update version : 6/0, messages 0
Outgoing update AS path filter list is 20
Unconditional default-originate
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
2.2.2.2
The template settings can be viewed using show ip bgp template {peer-session | peer-policy} command.
BGP Update Generation
The following are different methods of improving BGP update generation-
Peer groups
BGP dynamic update peer groups
Update packing enhancement
BGP read-only mode
This section will cover BGP peer groups.
Peer groups provide a mechanism for BGP peers that have the same outbound policy to be associated with each other. Peer groups provide two major benefits- configuration reduction and ability of replicate updates between peers.
The peer group is formed, and the common outbound policy is applied to the peer group. Each peer that has the same outbound policy is assigned to the peer group which greatly reduces redundant configuration on routers that have a large number of BGP peers.
A peer group is configured under BGP configuration and all the common outbound policies are applied to the peer-group.
Example peer-group configuration
Router(config)# router bgp 100
Router(config-router)# neighbor INTERNAL peer-group
Router(config-router)# neighbor INTERNAL version 4
Router(config-router)# neighbor INTERNAL remote-as 100
Router(config-router)# neighbor INTERNAL update-source Loopback 0
Router(config-router)# neighbor 2.2.2.2 peer-group INTERNAL
Router(config-router)# neighbor 3.3.3.3 peer-group INTERNAL
This greatly reduces redundant configuration in a large environment. Because all the peers have the same outbound policy, the update messages they send are the same. This means that the BGP update message is generated once for each peer-group and then is reused for all the neighbors.
Consider in a non-peer-group environment, the BGP process must walk the entire BGP table for every peer, and create updates for each peer independently. If there are 100 BGP routes and 100 BGP peers, the router must walk through the BGP table 100 times, essentially walking through 10,000 prefixes.
In a peer-group environment, BGP process walks the entire BGP table only once per peer-group. A peer-group leader is elected for each peer-group i.e. peer with lowest IP address. The BGP process walks the BGP table for the peer group leader, and creates update messages. These update messages are replicated for all other peer-group members. So, for 100 BGP peers, the router walks the BGP table only once, creates update messages for peer-group leader but all peer-group members receive the same update message. Hence, the router walk only 100 prefixes compared to 10,000 prefixes in non-peer-group environment. This reduces the processor and memory requirements.
The peer-group members must be in sync with the peer-group leader for replication to take place. The peer-group member is synchronized with the leader if the set of BGP paths advertised to the leader has also been advertised to peer-group member. If the peer-group member initializes after a peer-group is configured, the member will not be synchronized with the peer-group. In this case, the router updates the non-synchronized peer-group member as it would update a non-peer-group member until that peer becomes synchronized with the peer-group leader.
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
Addition of another peer Core-3 router:
Core-3 router also peers with Edge-1 router. The BGP table of Core-3 router is completely out-of-sync hence Edge-1 router will format UPDATE messages for Core-3 router individually until the BGP tables of all the members are in-sync. Until then the replication would not be perfect. If a next UPDATE message was to be advertised by Edge-1 router, it will be formatted for group-leader and replicated to all group-members including Core-3 router.
UPDATE message formation and replication
*Mar 1 17:31:08.671: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
Edge-1#
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (format) 10.1.1.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 10.2.2.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 1.1.1.1/32, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (format) 4.4.4.4/32, next 1.1.1.1, metric 0, path 200
*Mar 1 17:31:08.783: BGP(0): updgrp 1 - 5.5.5.5 updates replicated for neighbors:
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 3 2.2.2.2 11 9 0/1000 5/0
2 1 10.2.2.2 4 0 0/100 5/0
Peer groups
BGP dynamic update peer groups
Update packing enhancement
BGP read-only mode
This section will cover BGP peer groups.
Peer groups provide a mechanism for BGP peers that have the same outbound policy to be associated with each other. Peer groups provide two major benefits- configuration reduction and ability of replicate updates between peers.
The peer group is formed, and the common outbound policy is applied to the peer group. Each peer that has the same outbound policy is assigned to the peer group which greatly reduces redundant configuration on routers that have a large number of BGP peers.
A peer group is configured under BGP configuration and all the common outbound policies are applied to the peer-group.
Example peer-group configuration
Router(config)# router bgp 100
Router(config-router)# neighbor INTERNAL peer-group
Router(config-router)# neighbor INTERNAL version 4
Router(config-router)# neighbor INTERNAL remote-as 100
Router(config-router)# neighbor INTERNAL update-source Loopback 0
Router(config-router)# neighbor 2.2.2.2 peer-group INTERNAL
Router(config-router)# neighbor 3.3.3.3 peer-group INTERNAL
This greatly reduces redundant configuration in a large environment. Because all the peers have the same outbound policy, the update messages they send are the same. This means that the BGP update message is generated once for each peer-group and then is reused for all the neighbors.
Consider in a non-peer-group environment, the BGP process must walk the entire BGP table for every peer, and create updates for each peer independently. If there are 100 BGP routes and 100 BGP peers, the router must walk through the BGP table 100 times, essentially walking through 10,000 prefixes.
In a peer-group environment, BGP process walks the entire BGP table only once per peer-group. A peer-group leader is elected for each peer-group i.e. peer with lowest IP address. The BGP process walks the BGP table for the peer group leader, and creates update messages. These update messages are replicated for all other peer-group members. So, for 100 BGP peers, the router walks the BGP table only once, creates update messages for peer-group leader but all peer-group members receive the same update message. Hence, the router walk only 100 prefixes compared to 10,000 prefixes in non-peer-group environment. This reduces the processor and memory requirements.
The peer-group members must be in sync with the peer-group leader for replication to take place. The peer-group member is synchronized with the leader if the set of BGP paths advertised to the leader has also been advertised to peer-group member. If the peer-group member initializes after a peer-group is configured, the member will not be synchronized with the peer-group. In this case, the router updates the non-synchronized peer-group member as it would update a non-peer-group member until that peer becomes synchronized with the peer-group leader.
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
We configure two peer-groups on Edge-1 router- INTERNAL and EXTERNAL. Common outbound policies is applied to the peer-groups. Core-1 and Core-2 routers are assigned to INTERNAL peer-group while Edge-2 router is assigned to EXTERNAL peer-group.
INTERNAL peer-group on Edge-1
router bgp 100
neighbor INTERNAL peer-group
neighbor INTERNAL version 4
neighbor INTERNAL remote-as 100
neighbor INTERNAL password cisco
neighbor INTERNAL update-source Loopback 0
neighbor INTERNAL next-hop-self
neighbor 2.2.2.2 peer-group INTERNAL
neighbor 3.3.3.3 peer-group INTERNAL
!
EXTERNAL peer-group on Edge-1
router bgp 100
neighbor EXTERNAL peer-group
neighbor EXTERNAL version 4
neighbor EXTERNAL remote-as 200
neighbor EXTERNAL password cisco
neighbor 10.2.2.2 peer-group EXTERNAL
!
Verification:
The show ip bgp peer-group command is used to view the peer-groups and the members assigned to them.
show ip bgp peer-group
Edge-1# show ip bgp peer-group
BGP peer-group is INTERNAL, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is INTERNAL, peer-group internal, members:
2.2.2.2 3.3.3.3
Index 0, Offset 0, Mask 0x0
NEXT_HOP is always this router
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
BGP peer-group is EXTERNAL, remote AS 200
BGP version 4
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP neighbor is EXTERNAL, peer-group external, members:
10.2.2.2
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
The show ip bgp replication command displays update replication statistics for BGP update groups. As mentioned above, a peer-group leader is selected (Core-1 router, IP 2.2.2.2) for each peer-group. The router formats UPDATE messages for only the peer-group leader, and replicates the same messages to the peer-group members. The ratio of number of replicated message to number of formatted messages (MsgRepl/ MsgFmt) is called replication rate. In perfect replication, the replication rate is 1 less than the total number of members.
Here, the replication rate (MsgRepl/ MsgFmt) is 7/ 7 equals to 1. And the total number of members are 2. Hence, this is a perfect replication.
show ip bgp replication
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 2 2.2.2.2 7 7 0/1000 5/0
2 1 10.2.2.2 3 0 0/100 5/0
The following debug ip bgp updates out command shows that prefix 4.4.4.4/32 is formatted for peer-group leader 2.2.2.2 while it is replicated for 3.3.3.3
Addition of another peer Core-3 router:
Core-3 router also peers with Edge-1 router. The BGP table of Core-3 router is completely out-of-sync hence Edge-1 router will format UPDATE messages for Core-3 router individually until the BGP tables of all the members are in-sync. Until then the replication would not be perfect. If a next UPDATE message was to be advertised by Edge-1 router, it will be formatted for group-leader and replicated to all group-members including Core-3 router.
UPDATE message formation and replication
*Mar 1 17:31:08.671: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
Edge-1#
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (format) 10.1.1.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.675: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 10.2.2.0/24, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (prepend, chgflags: 0x0) 1.1.1.1/32, next 1.1.1.1, metric 0, path Local
*Mar 1 17:31:08.679: BGP(0): 5.5.5.5 send UPDATE (format) 4.4.4.4/32, next 1.1.1.1, metric 0, path 200
*Mar 1 17:31:08.783: BGP(0): updgrp 1 - 5.5.5.5 updates replicated for neighbors:
Edge-1# show ip bgp replication
Current Next
Index Members Leader MsgFmt MsgRepl Csize Version Version
1 3 2.2.2.2 11 9 0/1000 5/0
2 1 10.2.2.2 4 0 0/100 5/0
Load-balancing with 2 ISPs
Load-balancing with 2 ISPs
All hosts with IP addresses ranging from 192.168.1.1 - 192.168.1.126 (first-half) will be using ISP-1 while all hosts with IP addresses ranging from 192.168.1.129 - 192.168.1.254 (second-half) will be using ISP-2. In case of failover, hosts will be using the active ISP to access the Internet. NAT (NAT-overload) is applied on Edge routers to hide the inside network from the ISPs. The customer is using OSPF within the network. Both Edge routers use eBGP connection with the ISPs. Both ISPs only advertise default-route to the customer.
Splitting Host-traffic at Internal router:
On the Internal router, host-traffic is split based on the IP address of the host. Policy-based routing is used on the LAN interface and decision is made based on the IP address. If host IP address falls in the first-half, Internal router will forward the traffic over to Edge-1 router, while if host IP address falls in the second-half, Internal router will forward the traffic over to Edge-2 router. The set ip next-hop verify-availability command is used with tracking object to ensure the next-hop is available. If tracking-object fails, traffic is forwarded based on IP routing.
Splitting host-traffic
route-map Divide_Traffic permit 10
match ip address 110
set ip next-hop verify-availability 10.3.3.2 10 track 10
!
route-map Divide_Traffic permit 20
match ip address 120
set ip next-hop verify-availability 10.4.4.2 10 track 20
!
access-list 110 permit ip 192.168.1.0 0.0.0.127 any
access-list 120 permit ip 192.168.1.128 0.0.0.127 any
!
interface FastEthernet0/0
description LAN Interface
ip address 192.168.1.1 255.255.255.0
ip policy route-map Divide_Traffic
ip ospf 1 area 0
speed 100
full-duplex
!
Policy-Based Routing (PBR):
IP SLA is used to ensure the availability of next-hops. The IP address 4.2.2.2 is a global IP address on the Internet. To ensure the Internal router check both next-hops, two instances of IP SLAs are created on the router. Local policy-based routing is implemented to ensure packets originated by Internal router takes proper interfaces i.e. IP SLA packets with source address of 10.3.3.1 should go through Edge-1 router while IP SLA packets with source address of 10.4.4.1 should go through Edge-2 router.
PBR & Next-Hop availability
ip sla 1
icmp-echo 4.2.2.2 source-interface FastEthernet2/0
timeout 3000
threshold 2
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.2 source-interface FastEthernet3/0
timeout 3000
threshold 2
frequency 3
ip sla schedule 2 life forever start-time now
!
track 10 rtr 1 reachability
!
track 20 rtr 2 reachability
!
access-list 198 permit ip 10.4.4.0 0.0.0.255 any
access-list 199 permit ip 10.3.3.0 0.0.0.255 any
!
route-map LOCAL_TRAFFIC permit 10
match ip address 199
set ip next-hop 10.3.3.2
set interface FastEthernet2/0
!
route-map LOCAL_TRAFFIC permit 20
match ip address 198
set ip next-hop 10.4.4.2
set interface FastEthernet3/0
!
ip local policy route-map LOCAL_TRAFFIC
!
interface FastEthernet2/0
description Connection to Edge-1 router
ip address 10.3.3.1 255.255.255.0
ip ospf 1 area 0
speed 100
full-duplex
!
interface FastEthernet3/0
description Connection to Edge-2 router
ip address 10.4.4.1 255.255.255.0
ip ospf 1 area 0
speed 100
full-duplex
!
NAT on Edge routers:
On Edge-1 & Edge-2 routers, NAT is applied. The interesting traffic includes 192.168.1.0/24 network, 10.3.3.0/24 (on Edge-1) and 10.4.4.0/24 (on Edge-2).
NAT on Edge routers
Edge-1 router:
access-list 110 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 10.3.3.0 0.0.0.255 any
!
ip nat inside source list 110 interface Serial0/0 overload
!
interface Serial0/0
description To ISP-1
ip address 172.64.1.1 255.255.255.252
ip nat outside
!
interface FastEthernet0/1
ip address 10.3.3.2 255.255.255.0
ip nat inside
ip ospf 1 area 0
!
Edge-2 router:
access-list 110 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 10.4.4.0 0.0.0.255 any
!
ip nat inside source list 110 interface Serial0/0 overload
!
interface Serial0/0
description To ISP-2
ip address 172.64.2.1 255.255.255.252
ip nat outside
!
interface FastEthernet0/1
ip address 10.4.4.2 255.255.255.0
ip nat inside
ip ospf 1 area 0
!
In action:
The following output shows that both tracking-objects are UP.
Tacking Objects
Internal# show track
Track 10
Response Time Reporter 1 reachability
Reachability is Up
9 changes, last change 00:00:04
Latest operation return code: Over threshold
Latest RTT (millisecs) 48
Tracked by:
ROUTE-MAP 0
Track 20
Response Time Reporter 2 reachability
Reachability is Up
11 changes, last change 00:40:34
Latest operation return code: Over threshold
Latest RTT (millisecs) 32
Tracked by:
ROUTE-MAP 0
When a host (IP address: 192.168.1.129) tries to reach global IP address 4.2.2.2, the Internal router forwards the traffic over to Edge-2 router. While when a host (IP address 192.168.1.3) tries to reach same global IP address 4.2.2.2, the Internal router forwards the traffic over to Edge-1 router. The following output on Edge-2 & Edge-1 routers shows that NAT is applied on the source address (host IP address).
NAT on Edge routers
Edge-1# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.1.1:1 10.3.3.1:1 4.2.2.2:1 4.2.2.2:1
icmp 172.64.1.1:7 192.168.1.3:7 4.2.2.2:7 4.2.2.2:7
Edge-2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.2.1:2 10.4.4.1:2 4.2.2.2:2 4.2.2.2:2
icmp 172.64.2.1:6 192.168.1.129:6 4.2.2.2:6 4.2.2.2:6
Testing failover:
While host address (IP address 192.168.1.3) is continuously sending Ping packets to 4.2.2.2, ISP-1 fails. The tracking-object on the Internal router fails and packets are forwarded over to Edge-1 router.
Text Box
Edge-1# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.1.1:1 10.3.3.1:1 4.2.2.2:1 4.2.2.2:1
icmp 172.64.1.1:10 192.168.1.3:10 4.2.2.2:10 4.2.2.2:10
Internal#
01:54:19.171: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
Edge-2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.2.1:2 10.4.4.1:2 4.2.2.2:2 4.2.2.2:2
icmp 172.64.2.1:10 192.168.1.3:10 4.2.2.2:10 4.2.2.2:10
Host# ping 4.2.2.2 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.....!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 98 percent (494/500), round-trip min/avg/max = 1/65/264 ms
Host#
All hosts with IP addresses ranging from 192.168.1.1 - 192.168.1.126 (first-half) will be using ISP-1 while all hosts with IP addresses ranging from 192.168.1.129 - 192.168.1.254 (second-half) will be using ISP-2. In case of failover, hosts will be using the active ISP to access the Internet. NAT (NAT-overload) is applied on Edge routers to hide the inside network from the ISPs. The customer is using OSPF within the network. Both Edge routers use eBGP connection with the ISPs. Both ISPs only advertise default-route to the customer.
Splitting Host-traffic at Internal router:
On the Internal router, host-traffic is split based on the IP address of the host. Policy-based routing is used on the LAN interface and decision is made based on the IP address. If host IP address falls in the first-half, Internal router will forward the traffic over to Edge-1 router, while if host IP address falls in the second-half, Internal router will forward the traffic over to Edge-2 router. The set ip next-hop verify-availability command is used with tracking object to ensure the next-hop is available. If tracking-object fails, traffic is forwarded based on IP routing.
Splitting host-traffic
route-map Divide_Traffic permit 10
match ip address 110
set ip next-hop verify-availability 10.3.3.2 10 track 10
!
route-map Divide_Traffic permit 20
match ip address 120
set ip next-hop verify-availability 10.4.4.2 10 track 20
!
access-list 110 permit ip 192.168.1.0 0.0.0.127 any
access-list 120 permit ip 192.168.1.128 0.0.0.127 any
!
interface FastEthernet0/0
description LAN Interface
ip address 192.168.1.1 255.255.255.0
ip policy route-map Divide_Traffic
ip ospf 1 area 0
speed 100
full-duplex
!
Policy-Based Routing (PBR):
IP SLA is used to ensure the availability of next-hops. The IP address 4.2.2.2 is a global IP address on the Internet. To ensure the Internal router check both next-hops, two instances of IP SLAs are created on the router. Local policy-based routing is implemented to ensure packets originated by Internal router takes proper interfaces i.e. IP SLA packets with source address of 10.3.3.1 should go through Edge-1 router while IP SLA packets with source address of 10.4.4.1 should go through Edge-2 router.
PBR & Next-Hop availability
ip sla 1
icmp-echo 4.2.2.2 source-interface FastEthernet2/0
timeout 3000
threshold 2
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.2 source-interface FastEthernet3/0
timeout 3000
threshold 2
frequency 3
ip sla schedule 2 life forever start-time now
!
track 10 rtr 1 reachability
!
track 20 rtr 2 reachability
!
access-list 198 permit ip 10.4.4.0 0.0.0.255 any
access-list 199 permit ip 10.3.3.0 0.0.0.255 any
!
route-map LOCAL_TRAFFIC permit 10
match ip address 199
set ip next-hop 10.3.3.2
set interface FastEthernet2/0
!
route-map LOCAL_TRAFFIC permit 20
match ip address 198
set ip next-hop 10.4.4.2
set interface FastEthernet3/0
!
ip local policy route-map LOCAL_TRAFFIC
!
interface FastEthernet2/0
description Connection to Edge-1 router
ip address 10.3.3.1 255.255.255.0
ip ospf 1 area 0
speed 100
full-duplex
!
interface FastEthernet3/0
description Connection to Edge-2 router
ip address 10.4.4.1 255.255.255.0
ip ospf 1 area 0
speed 100
full-duplex
!
NAT on Edge routers:
On Edge-1 & Edge-2 routers, NAT is applied. The interesting traffic includes 192.168.1.0/24 network, 10.3.3.0/24 (on Edge-1) and 10.4.4.0/24 (on Edge-2).
NAT on Edge routers
Edge-1 router:
access-list 110 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 10.3.3.0 0.0.0.255 any
!
ip nat inside source list 110 interface Serial0/0 overload
!
interface Serial0/0
description To ISP-1
ip address 172.64.1.1 255.255.255.252
ip nat outside
!
interface FastEthernet0/1
ip address 10.3.3.2 255.255.255.0
ip nat inside
ip ospf 1 area 0
!
Edge-2 router:
access-list 110 permit ip 192.168.1.0 0.0.0.255 any
access-list 110 permit ip 10.4.4.0 0.0.0.255 any
!
ip nat inside source list 110 interface Serial0/0 overload
!
interface Serial0/0
description To ISP-2
ip address 172.64.2.1 255.255.255.252
ip nat outside
!
interface FastEthernet0/1
ip address 10.4.4.2 255.255.255.0
ip nat inside
ip ospf 1 area 0
!
In action:
The following output shows that both tracking-objects are UP.
Tacking Objects
Internal# show track
Track 10
Response Time Reporter 1 reachability
Reachability is Up
9 changes, last change 00:00:04
Latest operation return code: Over threshold
Latest RTT (millisecs) 48
Tracked by:
ROUTE-MAP 0
Track 20
Response Time Reporter 2 reachability
Reachability is Up
11 changes, last change 00:40:34
Latest operation return code: Over threshold
Latest RTT (millisecs) 32
Tracked by:
ROUTE-MAP 0
When a host (IP address: 192.168.1.129) tries to reach global IP address 4.2.2.2, the Internal router forwards the traffic over to Edge-2 router. While when a host (IP address 192.168.1.3) tries to reach same global IP address 4.2.2.2, the Internal router forwards the traffic over to Edge-1 router. The following output on Edge-2 & Edge-1 routers shows that NAT is applied on the source address (host IP address).
NAT on Edge routers
Edge-1# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.1.1:1 10.3.3.1:1 4.2.2.2:1 4.2.2.2:1
icmp 172.64.1.1:7 192.168.1.3:7 4.2.2.2:7 4.2.2.2:7
Edge-2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.2.1:2 10.4.4.1:2 4.2.2.2:2 4.2.2.2:2
icmp 172.64.2.1:6 192.168.1.129:6 4.2.2.2:6 4.2.2.2:6
Testing failover:
While host address (IP address 192.168.1.3) is continuously sending Ping packets to 4.2.2.2, ISP-1 fails. The tracking-object on the Internal router fails and packets are forwarded over to Edge-1 router.
Text Box
Edge-1# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.1.1:1 10.3.3.1:1 4.2.2.2:1 4.2.2.2:1
icmp 172.64.1.1:10 192.168.1.3:10 4.2.2.2:10 4.2.2.2:10
Internal#
01:54:19.171: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
Edge-2# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 172.64.2.1:2 10.4.4.1:2 4.2.2.2:2 4.2.2.2:2
icmp 172.64.2.1:10 192.168.1.3:10 4.2.2.2:10 4.2.2.2:10
Host# ping 4.2.2.2 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.....!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 98 percent (494/500), round-trip min/avg/max = 1/65/264 ms
Host#
Subscribe to:
Posts (Atom)