------------
This feature can be used when neighbor do not agreee on the AS. For example imagine
we have a
AS 200 and we are migrating to AS 100. All routers in the AS 100 have migrated to
the new AS
number of 100 apart from 1 router which is peering with an ISP who are being slow
updating there
neighbor statement to our new as 100
What we coould not is still use AS 100 on this router but tell the router for this
neighbor generate
the open message with the old AS 200
router bgp 100
neighbor 192.10.28.25 remote-as 254
neighbor 192.10.28.25 local-as 200 - this command says send open message with AS
100 in open
There is additional options for this command
neighbor 192.10.28.5 local-as 200 no-prepend
This no-prepend optiopn will not add the AS 200 to the AS path on routes it recieves
from the
neighbor AS
Another option is
neighbor 192.168.28.25 local-as 200 no-prepend replace-as dual-as
WHat this does is that when generating open commands to the particular neighbor
you will send both the proper/new AS of 100 and a as 200. It is for cases where
you know the provider is going change but not fully when this will allow support for
the provider to use either AS
Peer Groups
------------
Peer groups are a way of defining templates/groups with settings for neighbor
relationships . The same policy that goes to 1 neighbor in the peer group must go to all if it case one neighbor has a slightly different config we do not use peer-group for this neighbor
The idea being a group with all required bgp settings and then add the neighbors to
this group
so they inherit the settings.
It is for a bunch neighbors with the same required settings.
In cases like this it will make config easier less to input. But there is a
background enhancement
to the routing update process in that it will only generate 1 update for the peer
group rather than
a singular update for each neighbor. Also the best path selection only has to run
for the peer-group
not singular neighbors.
Router BGP 100
neighbor IBGP_PEERs peer-group - so you define the peer group name (in this case
IBGP_PEERS)
neighbor IBGP_PEERS remote-as 100
neighbor IBGP_PEERS update-source lo0 - so we are defining the settings for the peer
group that will
applied to all peers
neighbor 150.28.2.2 peer-group IBGP_PEERS
neighbor 150.28.3.1 peer-group IBGP_PEERS - you add peers to the template
then show output of sh ip bgp route
*=valif > = best i = ibgp i at the end is igp compared to ? which is redistributed
LAB
----
OK for the lab we see there is 2 AS 64512 & 64513. 64513 AS has only recently become
this as number it was previously AS 100. We are still waiting the server provider in
64512 to migrate neighbor so we need to make compatiable
on r4
r4
---
r4(config)#router bgp 64512
r4(config-router)#neighbor 172.25.13.5 remote-as 100
r4(config-router)#
r5
---
r5(config)#router bgp 64513
r5(config-router)#neighbor 172.25.13.4 remote-as 64512
r5(config)#e
*Jan 17 21:32:18.767: %BGP-3-NOTIFICATION: received from neighbor 172.25.13.4 2/2
(peer in wrong AS) 2 bytes FC01x
we are recieving a wrong as notification
r5(config)#router bgp 64513
r5(config-router)#neighbor 172.25.13.4 local-as 100
r4
---
r4#sh ip bgp summary
BGP router identifier 4.4.4.4, local AS number 64512
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.25.13.5 4 100 15 15 1 0 0 00:01:19 0
r4#
the relationship has come up
on r4
r4(config)#router bgp 64512
r4(config-router)#network 4.4.4.4 mask 255.255.255.255
r4(config-router)#
we will advertise how it appear on r5
on r5
r5#sh ip b
*Jan 17 21:39:22.219: %SYS-5-CONFIG_I: Configured from console by consolegp
BGP table version is 2, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 172.25.13.4 0 0 100 64512 i
see it is including the ASPath of 100 so even though it has only come from 1 AS
64512 it looks like it traversed 2
We may not want this to happen AS path is common attribute used in path selection
BGP maybe we want the info intact that is only 1 as away
so on r5
------------
r5(config)#router bgp 64513
r5(config-router)#neighbor 172.25.13.4 local-as 100 no?
no-prepend
r5(config-router)#neighbor 172.25.13.4 local-as 100 no-prepend
r5(config-router)#
*Jan 17 21:41:45.023: %BGP-5-ADJCHANGE: neighbor 172.25.13.4 Down Local AS change
*Jan 17 21:41:46.139: %BGP-5-ADJCHANGE: neighbor 172.25.13.4 Up
Now on the
r5#sh ip bgp
BGP table version is 4, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 172.25.13.4 0 0 64512 i
r5#
we are only seeing the one AS in the path
OK imagine now AS 64512 is planning on changing the AS it is neighboring with from
As 100 to the new AS 64513 we are not sure exactly when they are going change it
but we want that it will pick up auto overnight and be ready for the next morning
r5(config-router)#router bgp 64513
r5(config-router)#neighbor 172.25.13.4 local-as 100 no-prepend replace-as dual-as
r4 is still peering with 100
when i configured the command
*Jan 17 22:00:56.043: %BGP-5-ADJCHANGE: neighbor 172.25.13.4 Down Local AS change
*Jan 17 22:00:56.055: %BGP-3-NOTIFICATION: received from neighbor 172.25.13.4 2/2
(peer in wrong AS) 2 bytes FC01
r5#
*Jan 17 22:01:24.567: %SYS-5-CONFIG_I: Configured from console by console
*Jan 17 22:01:25.251: %BGP-5-ADJCHANGE: neighbor 172.25.13.4 Up
the neighbor relationship came down and then came backup
r4
---
lets image now the service provider has decided to change it is the middle night no
one is on site in our place
ON r4
------
r4(config)#router bgp 64512
r4(config-router)#no neighbor 172.25.13.5 remote-as 100
r4(config-router)#
*Jan 17 21:50:07.107: %BGP-5-ADJCHANGE: neighbor 172.25.13.5 Down Neighbor deleted
r4(config-router)#neighbor 172.25.13.5 remote-as 64513
r4(config-router)#
*Jan 17 21:50:39.247: %BGP-5-ADJCHANGE: neighbor 172.25.13.5 Up
It has come up without any additional changes on r5
lets imaging we have imagine we have to change back r4
r4(config)#router bgp 64512
r4(config-router)#neighbor 172.25.13.5 remote-as 100
r4(config-router)#
*Jan 17 21:51:24.351: %BGP-5-ADJCHANGE: neighbor 172.25.13.5 Down Remote AS changed
*Jan 17 21:51:26.363: %BGP-5-ADJCHANGE: neighbor 172.25.13.5 Up exit
the neighbor relationship goes down for a few seconds then comes backup it can peer
with either AS number
on switch 1
-----------
i will create an IBGP relationship with r5
switch1(config-router)#router bgp 64513
switch1(config-router)#neighbor 10.164.49.5 remote-as 64513
r5
----
r5(config-if)#router bgp 64513
r5(config-router)#neighbor 10.164.49.1 remote-as 64513
r5(config-router)#
r5#
*Jan 17 22:23:42.787: %SYS-5-CONFIG_I: Configured from console by console
*Jan 17 22:23:43.419: %BGP-5-ADJCHANGE: neighbor 10.164.49.1 Up
let have a look at the route we recieved from our ebgp session on r4
r5#sh ip bgp
BGP table version is 14, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 172.25.13.4 0 0 100 64512 i
*= it has valid next hop
>= it is the best route
i= it was learnt via Internal i.e it was not redistributed ? would be there if
redistributed
Lets look on s1
s1
---
switch1#sh ip bgp
BGP table version is 2, 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
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.4/32 172.25.13.4 0 100 0 100 64512 i
switch1#
the main things we notice is there is an i before the network ip saying it was
learnt via ibgp and the next hop has not changed
Typical when we are peering we will peer with the same config with all switches
within the AS apart from the ip
like for example you might
remote-as
update-source lo0
password
all this may be the same between neighbors lets create template for r5 connecting to
both sw1 and sw3
r5
---
r5(config-router)#router bgp 64513
r5(config-router)#neighbor AS_INTERNAL peer-group
r5(config-router)#neighbor AS_INTERNAL remote-as 64513
r5(config-router)#neighbor AS_INTERNAL update-source lo0
r5(config-router)#neighbor AS_INTERNAL password Cisco
r5(config-router)#
r5(config-router)#neighbor 3.3.3.3 peer-group AS_INTERNAL
r5(config-router)#neighbor 1.1.1.1 peer-group AS_INTERNAL
r5(config-router)#
r4
---
we can just copy in and paste just chaning the ip to our desired
switch1(config)#router bgp 64513
switch1(config-router)#router bgp 64513
switch1(config-router)#neighbor AS_INTERNAL peer-group
switch1(config-router)#neighbor AS_INTERNAL remote-as 64513
switch1(config-router)#neighbor AS_INTERNAL update-source lo0
switch1(config-router)#neighbor AS_INTERNAL password Cisco
switch1(config-router)#neighbor 5.5.5.5 peer-group AS_INTERNAL
switch1(config-router)#
switch1#
01:24:56: %SYS-5-CONFIG_I: Configured from console by console
01:25:14: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
this is also better for the router as it is only generating one update for the peer
group so 1 update for bot 1.1.1.1 and 3.3.3.3 and it only runs the best path
selection once for the peer group
No comments:
Post a Comment