BGP Local AS

Hello All
When using the local-as command under address-family ipv4 vrf, is the AS local to the specific Router or is it local to whole MPLS infrastructure?
Can anybody advise on this please?
Many Thanks in advance.

Hi Kaushik,
bgp local-as is per neighbor specific. You can have 2 neighbors on same router one with local-as and other without. By default, each router will include the AS number from "router bgp <as-number>" while sending the OPEN message. With bgp local-AS, you override it and make the router use the configured AS.
This command is useful incase of migration.
HTH,
Nagendra

Similar Messages

NX-OS vrf bgp local-as interaction with L3vpn

I use standard MPLS BGP-L3vpn to forward traffic between VRFs on Nexus 7k routers. All of my VRFs are within the same BGP process, so have the same local-as.
I'd like to bring-up an eBGP session from one VRF to a carrier, but the carriers requires that they peer with a specific BGP ASN (call it "65432"). It doesn't look like NX-OS supports the "router bgp 1234, vrf VRF1 neighbor w.x.y.z local-as 65432" command. However, it does appear to support "router bgp 1234, vrf VRF1, local-as 65432".
My limited understanding is that this would prepend "65432" onto all routes advertised to all VRF1 neighbors? And that all neighbors defined under VRF1 on this router would learn routes from me with as-path "^65432 1234 ..."?
If so, would this have any affect on routes exchanged with other VRFs using import/export rd?

It's tricky given that BGP's AD is always going to beat out EIGRP's all other things being equal. Most of the things you can do with BGP route-maps involve making one BGP route preferred over another.
You could inject the preferred path as a static route (AD = 1) to the firewall using an ip sla operation and having the static route track that. Once the ip sla operation fails, the static route is withdrawn and then the BGP-learned route (AD = 20) will take precedence.

Troubleshooting pfr configuration

I have recently configured PfR on our routers (Two routers) one as a MC and BR with 200 mbps internet connection directly conenctioned to MPLS and the other as a BR with 100 mbps internet connection directly connected to MPLS and change the aggrigation type to BGP and mode route is set to be on observe with below configuration,
The main purpose here by deploying PfR is to use PfR magic to have a redundent path/connection so if traffic on the 1st router hit the 75% of BW utilization treshhold,  the rest of the traffic (25%) would get re-routed to the 2nd router (100 mbps ).
I have been monitoring it for last few days but it doesnt seem to be working fine becaouse the trfaic on the primary router hitting almost 95 percent of its BW and nothing is being re-routed to the backup router!
All configuration looks to be fine and the connection status is success on both MC and BRs...
I am currently using PfR v. 3.3 on primary router and v.3.0 on back up router.
We are redistributing bgp to eigrp and eigrp to bgp using route-maps.
I wonder if anyone could provide some feedback so that i could fix and troubleshoot this issue and make it work.
BR configuration on the backup router :
===========================
sh run | s pfr
logging
local Loopback0
master xx.xx.xx.xx key-chain *******
sh pfr border
oer BR xx.xx.xx.xx ACTIVE, MC xx.xx.xx.xx UP/DOWN: UP 19:00:44
Auth Failures : 0
Conn Status : SUCCESS
OER Netflow Status : ENABLED, PORT : 3949
Version: 3.0   MC Version: 3.3
Exits
Gi 0/0      INTERNAL
Gi0/1       EXTERNAL
MC cofiguration on the primary router :
===========================
sh run | s pfr
pfr master
max-range-utilization percent 10
logging
border xx.xx.xx.xx key-chain *****
interface gi 0/1 external
interafce gi 0/0 internal
border xx.xx.xx.xx key-chain *****
interface gi 0/1 external
interafce gi 0/3 internal
learn
inside bgp
aggregation-type bgp
backoff 90 90
mode route observe
pfr border
local Loopback0
master xx.xx.xx.xx key-chain******
sh pfr master
OER State: ENABLES and ACTIVE
Conn Status : SUCCESS
Version: 3.3
Number of Border routers : 2
Number of Exits : 2
Number of monitored prerfixes : 210 (max 5000)
Max Prefixes : total 5000 learn 2500
Prefix count : total 210, learn 210, cfg 0
PBR Requirements not met
Nbar staus : Inactive
Auto Tunnel Mode : On
Global Settings:
max-range-utilization percent 10 recv 0
rsvp post-dial-delay 0 signaling-retries 1
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging
exit holddown time 60 secs, time remaining 0
Default Policy Settings:
backoff 90 90 90
delay relative 50
holddown 90
periodic 0
prob frequency 56
number of jitter probe packets 100
mode route observe
mode monitor both
loss relative 10
jitter threshhold 20
mos threshhold 3.60 percent 30
unreachable relative 50
trigger-log percentage 30
Learn Settings :
current state : STARTED
time remaining in current state : 70 seconds
throughput
no delay
inside bgp
monitor-period 1
periodic-interval 0
aggregation-type bgp
prefixes 100 appls 100
expire after time 720
======
Please let me know if you need additional details so that i can provide.
Thank you all.

Gentelmen,
Any help/comments please?
FYI> It learns all the traffic and prefixes and border router is now running the probes but when i run sh pfr border routes bgp the outcome is none...!!
Sh pfr master statitistics exit shows no activity on one of the border routers and it only shows activities on BR that is in MC router,
I can provide you more details if it would help,
The 2nd boder router doesnt have a direct conenction to master controler but the seeion has established per sh pfr master and sh pfr border.
Any feedback please?

Force Routing Over second link?

We have a MPLS WAN connecting our offices from our Service Provider. Our Head Office has a larger 50Mbps pipe and a remote office has 2 separate 2Mbps links (lets call them link1 and link2). Right now all traffic only goes over Link1 at the remote office as per all the BGP routing. I can make a static route at the remote office for specific traffic to go over link2 and it will successfully send over that link. My question is, is there a way to get traffic from Head Office to go to Link2 instead of Link1?

It primary depends on BGP routing. You can try to change the way ISP send traffic to you branch using different BGP path attribute in advertisement on the two links but you have to negotiated with ISP because they can also "force" their netwrok to use on path instead of the other for example using BGP local preference. I suggest you to read here to understand BGP algorithm:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Bye,
enrico

BGP decision algorithm nitty-gritty (relationship of locally originated routes to weight attribute)

Hello everyone, i have a question on this algorithm. Specifically the relationship between (cisco specific) WEIGHT which is right at the top of the path selection algorithm.... and routes that are ORIGINATED_LOCALLY (3rd one down, after weight and local_pref).
Heres the relevant steps of the decision tree:
1/WEIGHT (highest wins)
2/LOCAL_PREF (highest wins)
3/ORIGINATED LOCALLY (prefer locally originated over peer learnt)
Whats confusing to me is that Jeff's book tells us that if a prefix is ORIGINATED_LOCALLY (ie entered into BGP on that same router - either by a network/aggregate-address statement, or from redistribution) then its WEIGHT will also be set to 32768 (as opposed to a BGP peer learnt route whose WEIGHT is set to 0). I understand this.
My question is why??? Seems to me that if this is the case there is little purpose of having ORIGINATED_LOCALLY in the decision tree at all, as the logic will never get there on account of the the propagation of its value into (the higher up) WEIGHT decision. This also in turn means that ORIGINATED_LOCALLY has the power to override the attribute LOCAL_PREF.... so couldn't this whole logic be simplified to be:
1/WEIGHT or ORIGINATED LOCALLY
2/LOCAL_PREF (highest wins)
This very thing has confused another user on another post too, that user writes: "I tried thinking of an example where "ORIGINATED LOCALLY" works but weight doesn't, but couldn't think of any."
looking forward to the thoughts of this community.
Thanks in advance, Keiran.
PS> perhaps the attached diagram will help visualise this.

Thanks for your reply shaikhkamran123, i hadn't considered the multivendor environment (where cisco specific concept of 'weight' would be irrelevant to those routers), so yes their decision would start with:
1) Local Preference
2) Locally originated
as opposed to cisco
1/WEIGHT (highest wins)
2/LOCAL_PREF (highest wins)
3/ORIGINATED LOCALLY (prefer locally originated over peer learnt)
but it still doesn't really explain why cisco chose to alter their inbuilt weight based on if a route was locally originated. This alters the logic of the above decision algorithm: ie if its locally originated, it will set a high weight (32768), which will be preferred.... and heres the main thing *BEFORE* local_pref is even looked at. So in other words decision criteria#3, gets merged into #1, skipping ahead of #2. Am i going crazy here??
thanks in advance all...
K.

Link Local Address on BGP

I recently start to have IPv6 BGP Peer, at first I try to block all the link local address at my interface incoming ACL but after a while I notice that there has many match log on the deny link local address. I want to know is it a correct thing to not block link local address even the link is upstream link to my ISP?
My IPv6 BGP is formed by using Global IPv6 address!

Do you actually have a business need to block Link Local addresses ? This should not be done as the IPv6 control plane relies on link local addresses. e.g. each time you do a Neighbour Discovery on Ethernet. Link Local are also non routeable so they cannot traverse the router (assuming that is the intent of the ACL)
I would recommend against blocking Link Local addresses in ACLs however if you must do this you should be selective about the ones you allow through. e.g.
permit link_local_bgp_peer
deny all link_local
permit global uinicast
Though just beware that even then, if the upstream link local address changes, as in the upstream router swaps or replaces its interface then the ACL will have no effect as the Link Local address would have changed.

Link Local BGP peering between Cisco and Juniper (M-Series)

Hi,
has anybody successfully managed to get a working IPv6 session between a Cisco and a Juniper router using Link Local IPs?
I got it working between two cisco routers and two Juniper Routers but not with the two different vendors.
Configuration on the Juniper site:
   family inet6 {
       address FE80::1/64;
protocols {
      bgp {
          group customer_ipv6 {
              neighbor fe80::2 {
                  local-interface at-2/0/0.119;
                  peer-as 65300;
                  as-override;
Configuration on the Cisco site:
interface ATM0/0/0.1 point-to-point
bandwidth 2033
ip address 10.194.235.42 255.255.255.252
ip access-group AL-SECURITY-WAN out
ip mtu 1500
ipv6 address FE80::2 link-local
ipv6 enable
bfd interval 999 min_rx 999 multiplier 15
pvc 1/32
vbr-nrt 2244 2244 1
tx-ring-limit 3
encapsulation aal5snap
router bgp 65300
bgp router-id 10.213.58.185
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor FE80::1%ATM0/0/0.1 remote-as 65300
neighbor FE80::1%ATM0/0/0.1 version 4
neighbor FE80::2%GigabitEthernet0/1 remote-as 65300
neighbor FE80::2%GigabitEthernet0/1 version 4
address-family ipv4
exit-address-family
address-family ipv6
neighbor FE80::1%ATM0/0/0.1 activate
neighbor FE80::1%ATM0/0/0.1 advertisement-interval 5
neighbor FE80::1%ATM0/0/0.1 soft-reconfiguration inbound
neighbor FE80::1%ATM0/0/0.1 route-map NH6 out
neighbor FE80::2%GigabitEthernet0/1 activate
neighbor FE80::2%GigabitEthernet0/1 advertisement-interval 5
neighbor FE80::2%GigabitEthernet0/1 soft-reconfiguration inbound
neighbor FE80::2%GigabitEthernet0/1 route-map NH6 out
exit-address-family
CE_HOSTNAME# show ip bgp ipv6 uni su
BGP router identifier 10.213.58.185, local AS number 65300
BGP table version is 7, main routing table version 7
4 network entries using 656 bytes of memory
4 path entries using 320 bytes of memory
1/1 BGP path/bestpath attribute entries using 128 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
2 BGP community 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 1200 total bytes of memory
BGP activity 34/12 prefixes, 38/12 paths, scan interval 60 secs
Neighbor        V           AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd
FE80::1%ATM0/0/0.1
                4        65300       0       0        1    0    0 never    Idle
FE80::2%GigabitEthernet0/1
                4        65300      15      16        7    0    0 00:10:59        4
CE_HOSTNAME#
The console monitoring states the following:
Nov 10 06:30:33.023 MET: %BGP-3-NOTIFICATION: sent to neighbor FE80::1%ATM0/0/0.1 active 2/7 (unsupported/disjoint capability) 0 bytes
Nov 10 06:30:33.023 MET: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from FE80::1%ATM0/0/0.1:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 001D 0104 505A 005A 52D2 C023 00
Nov 10 06:30:33.023 MET: %BGP-3-NOTIFICATION: received from neighbor FE80::1%ATM0/0/0.1 active 2/5 (authentication failure) 0 bytes
de-ipc-ulmdon-ce-02#
Nov 10 06:30:33.023 MET: %BGP_SESSION-5-ADJCHANGE: neighbor FE80::1%ATM0/0/0.1 IPv6 Unicast topology base removed from session BGP Notification sent
The Cisco Router is running IOS 15.2, the Juniper Site JunOS 10.4
Any Ideas how I can get this to work?
Thanks in advance!

Marcin,
I updated the debugging log, the previous one was created using override-capability-neg on the neighbor (experimental).
>>0) Do you see similar scenario for working session? (Between two Cisco routers)
The working connection between two cisco routers doesn't show any output
>>1) What verion of IOS are you running? Something failrly recent I hope?
Show Version:
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.2(1)T1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Mon 19-Sep-11 16:24 by prod_rel_team
ROM: System Bootstrap, Version 15.0(1r)M9, RELEASE SOFTWARE (fc1)
CE_HOSTNAME uptime is 2 weeks, 5 days, 21 hours, 35 minutes
System returned to ROM by reload at 18:43:21 MET(S) Fri Oct 21 2011
System restarted at 18:44:50 MET(S) Fri Oct 21 2011
System image file is "flash:c1900-universalk9-mz.SPA.152-1.T1.bin"
Last reload type: Normal Reload
Last reload reason: Reload Command
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
[email protected].
Cisco CISCO1941/K9 (revision 1.0) with 446464K/77824K bytes of memory.
Processor board ID FCZ1504C0G8
1 DSL controller
2 Gigabit Ethernet interfaces
1 ATM interface
1 terminal line
DRAM configuration is 64 bits wide with parity disabled.
255K bytes of non-volatile configuration memory.
250880K bytes of ATA System CompactFlash 0 (Read/Write)
License Info:
License UDI:
Device#   PID                   SN
*0        CISCO1941/K9          FCZ1504C0G8
Technology Package License Information for Module:'c1900'
Technology    Technology-package           Technology-package
              Current       Type           Next reboot
ipbase        ipbasek9      Permanent      ipbasek9
security      None          None           None
data          datak9        Permanent      datak9
Configuration register is 0x2102
>>2) Can we have some more info from Juniper side (logs/debugs).
Sadly not. The Juniper Traceoptions don't show anything
All I can offer you at this point is the neighbor show command:
user@Juniper> show bgp neighbor fe80::2 instance vrf-test
Peer: fe80::2 AS 65300         Local: unspecified AS 20570
Type: External    State: Idle           Flags:
Last State: NoState       Last Event: NoEvent
Last Error: None
Export: [ pol-standard-bgp-export ] Import: [ pol-standard-bgp-import ]
Options:
Options:
Address families configured: inet6-unicast
Path-attributes dropped: 128
Holdtime: 90 Preference: 170
Number of flaps: 0
Trace options: all
Trace file: /var/log/bgp_ipv6_ll_20111110 size 131072 files 10
user@Juniper> show bgp summary instance vrf-test
Groups: 2 Peers: 2 Down peers: 1
Table          Tot Paths Act Paths Suppressed    History Damp State    Pending
vrf-2.inet.0          37         16          0          0          0          0
vrf-.inet6.0           0          0          0          0          0          0
vrf-24.mdt.0           0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.194.235.42         65300       1149       1076       0       1     8:44:00 Establ
vrf-test.inet.0: 6/7/7/0
fe80::2               65300          0          0       0       0     9:38:32 Idle
>>3)
CE_HOSTNAME#
Nov 10 15:35:49.574 MET: BGP: ses global 10.194.235.41 (0x2970EDA4:1) Keep alive timer fired.
Nov 10 15:35:49.574 MET: BGP: 10.194.235.41 KEEPALIVE requested (bgp_keepalive_timer_expired)
Nov 10 15:35:49.574 MET: BGP: ses global 10.194.235.41 (0x2970EDA4:1) service keepalive IO request.
Nov 10 15:35:49.574 MET: BGP: 10.194.235.41 KEEPALIVE write request serviced in BGP_IO
CE_HOSTNAME#
Nov 10 15:35:50.598 MET: BGP: ses global FE80::2%GigabitEthernet0/1 (0x316FBDDC:1) Keep alive timer fired.
Nov 10 15:35:50.598 MET: BGP: FE80::2%GigabitEthernet0/1 KEEPALIVE requested (bgp_keepalive_timer_expired)
Nov 10 15:35:50.598 MET: BGP: ses global FE80::2%GigabitEthernet0/1 (0x316FBDDC:1) service keepalive IO request.
Nov 10 15:35:50.598 MET: BGP: FE80::2%GigabitEthernet0/1 KEEPALIVE write request serviced in BGP_IO
CE_HOSTNAME#
Nov 10 15:35:52.850 MET: BGP: 10.194.235.41 received KEEPALIVE, length (excl. header) 0
CE_HOSTNAME#
Nov 10 15:35:54.694 MET: BGP: FE80::1%ATM0/0/0.1 active went from Idle to Active
Nov 10 15:35:54.694 MET: BGP: FE80::1%ATM0/0/0.1 open active, local address FE80::2
Nov 10 15:35:54.698 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Adding topology IPv6 Unicast:base
Nov 10 15:35:54.698 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Send OPEN
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active went from Active to OpenSent
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active sending OPEN, version 4, my as: 65300, holdtime 180 seconds, ID AD53AB9
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active KEEPALIVE write request serviced in BGP_IO
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active KEEPALIVE write request serviced in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv message type 1, length (excl. header) 10
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Receive OPEN
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv OPEN, version 4, holdtime 90 seconds
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv OPEN w/ OPTION parameter len: 0
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active went from OpenSent to Closing
Nov 10 15:35:54.702 MET: %BGP-3-NOTIFICATION: sent to neighbor FE80::1%ATM0/0/0.1 active 2/7 (unsupported/disjoint capability) 0 bytes
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Send NOTIFICATION 2/7 (unsupported/disjoint capability) 0 bytes
Nov 10 15:35:54.702 MET: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from FE80::1%ATM0/0/0.1:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 001D 0104 505A 005A 52D2 C023 00
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv message type 3, length (excl. header) 2
Nov 10 15:35:54.702 MET: %BGP-3-NOTIFICATION: received from neighbor FE80::1%ATM0/0/0.1 active 2/5 (authentication failure) 0 bytes
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active bad state change from Closing to Closing
Nov 10 15:35:54.702 MET: -Traceback= 21B3370Cz 21B33C74z 21B34258z
Nov 10 15:35:54.702 MET: BGP: tbl IPv4 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl IPv6 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl VPNv4 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl VPNv6 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl IPv4 Multicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) NSF delete stale NSF not active
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) NSF no stale paths state is NSF not active
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) Resetting ALL counters.
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active closing
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Session close and reset neighbor FE80::1%ATM0/0/0.1 topostate
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) Resetting ALL counters.
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active went from Closing to Idle
Nov 10 15:35:54.702 MET: %BGP_SESSION-5-ADJCHANGE: neighbor FE80::1%ATM0/0/0.1 IPv6 Unicast topology base removed from session BGP Notification sent
CE_HOSTNAME#CE_HOSTNAME#
Nov 10 15:35:49.574 MET: BGP: ses global 10.194.235.41 (0x2970EDA4:1) Keep alive timer fired.
Nov 10 15:35:49.574 MET: BGP: 10.194.235.41 KEEPALIVE requested (bgp_keepalive_timer_expired)
Nov 10 15:35:49.574 MET: BGP: ses global 10.194.235.41 (0x2970EDA4:1) service keepalive IO request.
Nov 10 15:35:49.574 MET: BGP: 10.194.235.41 KEEPALIVE write request serviced in BGP_IO
CE_HOSTNAME#
Nov 10 15:35:50.598 MET: BGP: ses global FE80::2%GigabitEthernet0/1 (0x316FBDDC:1) Keep alive timer fired.
Nov 10 15:35:50.598 MET: BGP: FE80::2%GigabitEthernet0/1 KEEPALIVE requested (bgp_keepalive_timer_expired)
Nov 10 15:35:50.598 MET: BGP: ses global FE80::2%GigabitEthernet0/1 (0x316FBDDC:1) service keepalive IO request.
Nov 10 15:35:50.598 MET: BGP: FE80::2%GigabitEthernet0/1 KEEPALIVE write request serviced in BGP_IO
CE_HOSTNAME#
Nov 10 15:35:52.850 MET: BGP: 10.194.235.41 received KEEPALIVE, length (excl. header) 0
CE_HOSTNAME#
Nov 10 15:35:54.694 MET: BGP: FE80::1%ATM0/0/0.1 active went from Idle to Active
Nov 10 15:35:54.694 MET: BGP: FE80::1%ATM0/0/0.1 open active, local address FE80::2
Nov 10 15:35:54.698 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Adding topology IPv6 Unicast:base
Nov 10 15:35:54.698 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Send OPEN
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active went from Active to OpenSent
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active sending OPEN, version 4, my as: 65300, holdtime 180 seconds, ID AD53AB9
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active KEEPALIVE write request serviced in BGP_IO
Nov 10 15:35:54.698 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active KEEPALIVE write request serviced in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active service 2 read request in BGP_IO
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv message type 1, length (excl. header) 10
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Receive OPEN
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv OPEN, version 4, holdtime 90 seconds
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv OPEN w/ OPTION parameter len: 0
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active went from OpenSent to Closing
Nov 10 15:35:54.702 MET: %BGP-3-NOTIFICATION: sent to neighbor FE80::1%ATM0/0/0.1 active 2/7 (unsupported/disjoint capability) 0 bytes
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Send NOTIFICATION 2/7 (unsupported/disjoint capability) 0 bytes
Nov 10 15:35:54.702 MET: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from FE80::1%ATM0/0/0.1:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 001D 0104 505A 005A 52D2 C023 00
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active rcv message type 3, length (excl. header) 2
Nov 10 15:35:54.702 MET: %BGP-3-NOTIFICATION: received from neighbor FE80::1%ATM0/0/0.1 active 2/5 (authentication failure) 0 bytes
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active bad state change from Closing to Closing
Nov 10 15:35:54.702 MET: -Traceback= 21B3370Cz 21B33C74z 21B34258z
Nov 10 15:35:54.702 MET: BGP: tbl IPv4 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl IPv6 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl VPNv4 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl VPNv6 Unicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: tbl IPv4 Multicast:base Service reset requests
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) NSF delete stale NSF not active
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) NSF no stale paths state is NSF not active
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) Resetting ALL counters.
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active closing
Nov 10 15:35:54.702 MET: BGP: ses global FE80::1%ATM0/0/0.1 (0x296337B4:0) act Session close and reset neighbor FE80::1%ATM0/0/0.1 topostate
Nov 10 15:35:54.702 MET: BGP: nbr_topo global FE80::1%ATM0/0/0.1 IPv6 Unicast:base (0x296337B4:0) Resetting ALL counters.
Nov 10 15:35:54.702 MET: BGP: FE80::1%ATM0/0/0.1 active went from Closing to Idle
Nov 10 15:35:54.702 MET: %BGP_SESSION-5-ADJCHANGE: neighbor FE80::1%ATM0/0/0.1 IPv6 Unicast topology base removed from session BGP Notification sent
CE_HOSTNAME#

BGP Community | Route-Map | Local Pref

While labbing today I've ran into some strange behavior with BGP communities/route-map processing. Basically the objective was from R9, send a community for the 172.30.79.0/27 route out to R7 to 65100:90 AND send a community for the 172.30.89.0/27 route out to R8 to 65100:110. Then on R9 match community 65100:90 and set the local-pref to 90 and 65100:110 to local-pref of 110. Should be easy enough but the behavior that i'm seeing is that all is working on R7 but not on R8. The R8 inbound route-map is watching the community but not setting the local-pref for some reason... Any ideas? See below.
Topology
##R9’s BGP/Route-map config setting communities for the two routes out to R7 & R8##
R9#sh run | s bgp|route-map
router bgp 65100
network 172.30.79.0 mask 255.255.255.224
network 172.30.89.0 mask 255.255.255.224
network 192.122.3.9 mask 255.255.255.255
neighbor 172.30.79.7 remote-as 65006
neighbor 172.30.79.7 send-community both
neighbor 172.30.79.7 route-map R7-OUT out
neighbor 172.30.89.8 remote-as 65006
neighbor 172.30.89.8 send-community both
neighbor 172.30.89.8 route-map R8-OUT out
ip bgp-community new-format
route-map R7-OUT permit 10
match ip address prefix-list 172.30.79.0/27
set community 65100:90
route-map R7-OUT permit 20
route-map R8-OUT permit 10
match ip address prefix-list 172.30.89.0/27
set community 65100:110
route-map R8-OUT permit 20
##R7’s config##
R7#sh run | s bgp|route-map
router bgp 65006
address-family ipv4 vrf VPN
neighbor 172.30.79.9 remote-as 65100
neighbor 172.30.79.9 activate
neighbor 172.30.79.9 send-community both
neighbor 172.30.79.9 as-override
neighbor 172.30.79.9 route-map R9-IN in
route-map R9-IN permit 10
match community 65100:90
set local-preference 90
route-map R9-IN permit 20
##R7’s ‘show bgp’##
R7#sh ip bgp vpnv4 vrf VPN | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65066:700 (default for vrf VPN)
r> 172.30.79.0/27   172.30.79.9           90             0 65100 i
*> 172.30.89.0/27   172.30.79.9              0             0 65100 i
*> 192.122.3.9/32   172.30.79.9              0             0 65100 i
##R8’s config##
router bgp 65006
address-family ipv4 vrf VPN
neighbor 172.30.89.9 remote-as 65100
neighbor 172.30.89.9 activate
neighbor 172.30.89.9 send-community both
neighbor 172.30.89.9 as-override
neighbor 172.30.89.9 route-map R9-INv2 in
route-map R9-INv2 permit 10
match community 65100:110
set local-preference 110
route-map R9-INv2 permit 20
##R8’s ‘show bgp’##
R8#sh ip bgp vpnv4 vrf VPN | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65006:800 (default for vrf VPN)
*> 172.30.79.0/27   172.30.89.9              0             0 65100 i
r> 172.30.89.0/27   172.30.89.9              0             0 65100 i
*> 192.122.3.9/32   172.30.89.9              0             0 65100 i
R8#sh ip bgp vpnv4 vrf VPN community | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65006:800 (default for vrf VPN)
r> 172.30.89.0/27   172.30.89.9              0             0 65100 i
R8#sh ip bgp vpnv4 vrf VPN 172.30.89.0/27
BGP routing table entry for 65006:800:172.30.89.0/27, version 77
Paths: (1 available, best #1, table VPN, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 2
65100
    172.30.89.9 from 172.30.89.9 (192.122.3.9)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 65100:110
      Extended Community: RT:910:910
      mpls labels in/out 45/nolabel
      rx pathid: 0, tx pathid: 0x0

While labbing today I've ran into some strange behavior with BGP communities/route-map processing. Basically the objective was from R9, send a community for the 172.30.79.0/27 route out to R7 to 65100:90 AND send a community for the 172.30.89.0/27 route out to R8 to 65100:110. Then on R9 match community 65100:90 and set the local-pref to 90 and 65100:110 to local-pref of 110. Should be easy enough but the behavior that i'm seeing is that all is working on R7 but not on R8. The R8 inbound route-map is watching the community but not setting the local-pref for some reason... Any ideas? See below.
Topology
##R9’s BGP/Route-map config setting communities for the two routes out to R7 & R8##
R9#sh run | s bgp|route-map
router bgp 65100
network 172.30.79.0 mask 255.255.255.224
network 172.30.89.0 mask 255.255.255.224
network 192.122.3.9 mask 255.255.255.255
neighbor 172.30.79.7 remote-as 65006
neighbor 172.30.79.7 send-community both
neighbor 172.30.79.7 route-map R7-OUT out
neighbor 172.30.89.8 remote-as 65006
neighbor 172.30.89.8 send-community both
neighbor 172.30.89.8 route-map R8-OUT out
ip bgp-community new-format
route-map R7-OUT permit 10
match ip address prefix-list 172.30.79.0/27
set community 65100:90
route-map R7-OUT permit 20
route-map R8-OUT permit 10
match ip address prefix-list 172.30.89.0/27
set community 65100:110
route-map R8-OUT permit 20
##R7’s config##
R7#sh run | s bgp|route-map
router bgp 65006
address-family ipv4 vrf VPN
neighbor 172.30.79.9 remote-as 65100
neighbor 172.30.79.9 activate
neighbor 172.30.79.9 send-community both
neighbor 172.30.79.9 as-override
neighbor 172.30.79.9 route-map R9-IN in
route-map R9-IN permit 10
match community 65100:90
set local-preference 90
route-map R9-IN permit 20
##R7’s ‘show bgp’##
R7#sh ip bgp vpnv4 vrf VPN | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65066:700 (default for vrf VPN)
r> 172.30.79.0/27   172.30.79.9           90             0 65100 i
*> 172.30.89.0/27   172.30.79.9              0             0 65100 i
*> 192.122.3.9/32   172.30.79.9              0             0 65100 i
##R8’s config##
router bgp 65006
address-family ipv4 vrf VPN
neighbor 172.30.89.9 remote-as 65100
neighbor 172.30.89.9 activate
neighbor 172.30.89.9 send-community both
neighbor 172.30.89.9 as-override
neighbor 172.30.89.9 route-map R9-INv2 in
route-map R9-INv2 permit 10
match community 65100:110
set local-preference 110
route-map R9-INv2 permit 20
##R8’s ‘show bgp’##
R8#sh ip bgp vpnv4 vrf VPN | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65006:800 (default for vrf VPN)
*> 172.30.79.0/27   172.30.89.9              0             0 65100 i
r> 172.30.89.0/27   172.30.89.9              0             0 65100 i
*> 192.122.3.9/32   172.30.89.9              0             0 65100 i
R8#sh ip bgp vpnv4 vrf VPN community | b Network
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65006:800 (default for vrf VPN)
r> 172.30.89.0/27   172.30.89.9              0             0 65100 i
R8#sh ip bgp vpnv4 vrf VPN 172.30.89.0/27
BGP routing table entry for 65006:800:172.30.89.0/27, version 77
Paths: (1 available, best #1, table VPN, RIB-failure(17))
Not advertised to any peer
Refresh Epoch 2
65100
    172.30.89.9 from 172.30.89.9 (192.122.3.9)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 65100:110
      Extended Community: RT:910:910
      mpls labels in/out 45/nolabel
      rx pathid: 0, tx pathid: 0x0

CRS, IOS-XR: local IGP route not installed in BGP table when learned from RR

Hello,
We use CRS routers in our IGP/BGP network core, some of which are acting as BGP originators and reflectors (RRs) for IPv4 unicast. We also use CRS routers as Internet PEs. The problem we have is between those PEs and the core routers.
Premise: each Internet PE is terminating customer cisrcuits and injects those downstream routes in IGP (via redistributing static, or just learned via IGP from a downstream router). The core (P) routers then learn those routes from the PE via the IGP. Two of the P-routers act as BGP originators and install the necessary routes in BGP using the network statement. These routes are mostly supernets (i.e. summarized), but some coincide with IGP routes, as learned from the PEs. The P-routers acting as RRs then reflect all iBGP routes to all IPv4 unicast BGP speakers in the network, including the Internet PEs (we also have BGP peers on those PEs, which is why this is necessary).
Problem: if a specific downstream route, learned on an Internet PE via IGP (i.e. from downstream), is then received by that PE from an RR via iBGP (i.e. from upstream), the route is not installed in the BGP table (the output of the show bgp x.x.x.x/xx command is: Network not in table)
Question: does anyone know why this is happening? This is concictent on all of our CRS PEs. As far as I am aware there is no BGP rule that would explain this behavior. We don't expect the PE to prefer the iBGP route over the IGP route, but that should not prevent it from learning it and installing it in the BGP table... The only discrepancy I could think of is that the IGP route has a next-hop pointing downstream, whereas the the same route, learned over iBGP has a next-hop pointing upstream. Then again,this shouldn't prevent the route to appear in the BGP table....
Your help would be appreciated!
Thanks!

Hi !
If I am understandung you correctly then Split Horizon is the keyword
Because if the route is learned from downstream BGP drops any same path information learned from upstream
SPLIT-HORIZON only applies to distance-vector routing protocols. In case of BGP, it simply means that a prefix learned via a peer is not advertised back to that peer.
Split horizon will simply block out routes with the same neighbor as the next-hop for the router
regards
alexander

Load balance not happening in BGP

Dear Friends,
As per I know local BGP process may implement equal-cost load-balancing to the paths that:
Have the same set of path attributes up to the MED (weight, Local Preference, Origin, MED)
Are of the same type (both learned via iBGP or eBGP)
Have the same IGP cost to reach their NEXT_HOP IP address
If the above conditions are met andmaximum-paths [ibgp]is configured under the BGP process, BGP will install multiple equal-cost routes into the local RIB and use them for load-balancing. We call the above condition as load-balancing conditions for BGP.
As all the above criteria are matched still BGP is not doing load balance. Please find below routing table:
R1:
R1#sh ip bgp
BGP table version is 4, local router ID is 40.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
*>i192.168.1.0      20.1.1.2                 0    100      0 i
* i                        30.1.1.1                 0    100      0 i
R1#sh ip route
Gateway of last resort is not set
     20.0.0.0/24 is subnetted, 1 subnets
R       20.1.1.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
     40.0.0.0/24 is subnetted, 1 subnets
C       40.1.1.0 is directly connected, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
B    192.168.1.0/24 [200/0] via 20.1.1.2, 00:12:01
     30.0.0.0/24 is subnetted, 1 subnets
R       30.1.1.0 [120/1] via 40.1.1.2, 00:00:15, FastEthernet0/1
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 100
neighbor 40.1.1.2 remote-as 100
maximum-paths 2
no auto-summary
Please help....!!!!!!!   why BGP is not load balancing here????
R1#traceroute 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 10.1.1.2 88 msec 60 msec 28 msec
2 20.1.1.2 104 msec 56 msec 120 msec
Regards,
Sanjib

Dear Jon,
Thank you so much.
When I changed the configuration BGP is now loadbalancing. But in configuartion Max-path showing as 1 instead of 2.
R1#sh ip pro | sec bgp
Routing Protocol is "bgp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    12.1.1.2
    13.1.1.3
Maximum path: 1
Routing Information Sources:
    Gateway         Distance      Last Update
    13.1.1.3             200      00:01:12
    12.1.1.2             200      00:02:15
Distance: external 20 internal 200 local 200
Regards,
Sanjib

Can you display routes advertised and/or received in OSPF, similar to BGP command sh ip bgp neighbors x.x.x.x advertised-routes?

TOC-BP-SWa#sh ip bgp neighbors 10.14.0.3 advertised-routes
BGP table version is 1674320, local router ID is 10.14.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.14.0.1/32 0.0.0.0 0 32768 i
*> 147.249.37.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
*> 147.249.38.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
*> 147.249.46.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 12159 12159 i
*> 147.249.196.0/24 172.20.18.1 120 0 2001 65015 65016 64823 64870 65124 i
*> 147.249.237.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
TOC-BP-SWa#sh ip bgp neighbors 10.14.0.3 received-r
Total number of prefixes 0
TOC-BP-SWa#sh ip bgp neighbors 10.14.0.2 received-r
BGP table version is 1674320, local router ID is 10.14.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.14.0.2/32 10.14.0.2 0 100 0 i
* i147.249.37.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
* i147.249.38.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
* i147.249.46.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 12159 12159 i
* i147.249.196.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 64870 65124 i
* i147.249.237.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
Can this output be duplicated with an OSPF command?

Not really because OSPF does not advertise routes it sends LSAs to it's peers.
So you need to look at the OSPF database ie. -
"sh ip ospf database"
which will show you all the LSAs the router is aware of.
In terms of all the LSAs the router has received it will show all of those but it will also show you LSAs that were generated by the router itself although the advertising router IP will point to that being the case.
In terms of all the LSAs the router advertises again it depends on the area and how that has been configured.
So for example an ABR might well have external LSAs (which aren't tied to any area in the OSPF database) but that doesn't necessarily mean it is advertising them to peers within an area as it could have been configured not to.
So it gives you a good idea but you need to also work out a few things for yourself as well.
Jon

BGP, VRF and PBR ("set vrf")

Hi networkers!
Requirements:
- 2 locations (OFFICE, DC) in the same town
- each having two active WAN connections (carrying individual routing domains): The default Any2Any WAN (where several other locations are connected to) and a client specific MC WAN.
- There is a high speed "metro" connection between the locations
- Targets of MC WAN must only be available from a dedicated "MC LAN" network segment
- The default route of "MC LAN" is into Any2Any. Some specific routes coming from MC WAN will overrule A2A routes
- By default, all locally generated traffic should leave into the local WAN links
- In case of a local fault, the locally generated traffic should go via "metro" link into the remote WAN links.
- Traffic between office and DC has to use the metro link.
Hardware: Cat 4500X in VSS configuration at both locations acting as router.
The challenge is with the "MC LAN" that should be fully integrated into A2A routing (communicating locally with devices in other LAN segments and remotely with other sites) but it should also communicate with some special targets of the MC WAN that all other LAN segments must not see.
The general solution that I found is to set the "MC LAN segment" into the GRT but apply "ip vrf receive VRF_MC" and "set vrf VRF_MC" as PBR for targets that should be reached via MC-WAN. It is makes me a little unhappy, that I have to configure a static PBR "routing" because the MC routes are already available by BGP within VRF_MC. But I have tested several other solutions (route leackage e.g.). But they did not work (route leakage for example is not possible on-device between VLANs but only between physical ports).
I put in here only the OFFICE part of the configuration. At the DC there is no "MC LAN" only "MC WAN" which is fully isolated by VRF.
We create two transfer networks at each side. One for the Metro and one for the WAN and start BGP sessions with the neighbors. Failover is guaranteed by longer AS-PATH:
vrf definition VRF_MC
description MC routing domain
rd 65500:1
address-family ipv4
exit-address-family
interface Vlan3
description MC Office
ip vrf receive VRF_MC
ip address 1.40.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip policy route-map MC_PBR_VRF
interface Vlan30
description WAN A2A transfer (partner 2.2.2.18 // remote-as 65293 - local AS 65502)
ip address 2.2.2.21 255.255.255.240
interface Vlan31
description WAN MC(partner 2.2.2.50 // remote-as 65293 - local AS 65502)
vrf forwarding VRF_MC
ip address 2.2.2.53 255.255.255.240
interface Vlan34
description Metro A2A transfer (partner 3.3.3.69 remote-as 65503)
ip address 3.3.3.66 255.255.255.240
interface Vlan36
description Metro MC transfer (partner 3.3.3.85 remote-as 65503)
vrf forwarding VRF_MC
ip address 3.3.3.82 255.255.255.240
router bgp 65502
bgp always-compare-med
bgp log-neighbor-changes
network 1.40.1.0 mask 255.255.255.0        <-- MC LAN
network 1.1.192.0 mask 255.255.248.0       <-- other Office LAN segments below
network 1.1.200.0 mask 255.255.248.0
network 1.1.208.0 mask 255.255.248.0
neighbor 2.2.2.18 remote-as 65293
neighbor 2.2.2.18 description to_A2A_WAN
neighbor 2.2.2.18 version 4
neighbor 2.2.2.18 remove-private-as
neighbor 2.2.2.18 soft-reconfiguration inbound
neighbor 2.2.2.18 prefix-list BGP_A2A_out out
neighbor 3.3.3.69 remote-as 65503
neighbor 3.3.3.69 description A2A_Metro_to_DC
neighbor 3.3.3.69 update-source Vlan34
neighbor 3.3.3.69 version 4
neighbor 3.3.3.69 soft-reconfiguration inbound
address-family ipv4 vrf VRF_MC
network 1.40.1.0 mask 255.255.255.0         <-- MC LAN
neighbor 2.2.2.50 remote-as 65293
neighbor 2.2.2.50 description to_MC_WAN
neighbor 2.2.2.50 version 4
neighbor 2.2.2.50 activate
neighbor 2.2.2.50 remove-private-as
neighbor 2.2.2.50 soft-reconfiguration inbound
neighbor 2.2.2.50 prefix-list BGP_MC_out out
neighbor 3.3.3.85 remote-as 65503
neighbor 3.3.3.85 description MC_Metro_to_DC
neighbor 3.3.3.85 update-source Vlan36
neighbor 3.3.3.85 activate
neighbor 3.3.3.85 soft-reconfiguration inbound
exit-address-family
route-map MC_PBR_VRF permit 10
match ip address MC_PBR_ROUTE
set vrf VRF_MC
! control BGP
ip prefix-list BGP_A2A_out seq 10 permit 1.1.192.0/21 le 32
ip prefix-list BGP_A2A_out seq 20 permit 1.1.200.0/21 le 32
ip prefix-list BGP_A2A_out seq 30 permit 1.1.208.0/21 le 32
ip prefix-list BGP_A2A_out seq 40 permit 1.40.1.0/24 le 32
! control BGP
ip prefix-list BGP_MC_out seq 10 permit 1.40.1.0/24 le 32
ip access-list extended MC_PBR_ROUTE
permit ip any 2.2.2.48 0.0.0.15
permit ip any 3.3.3.80 0.0.0.15
permit ip any 7.87.208.0 0.0.15.255
permit ip any 55.55.0.0 0.0.0.255
permit ip any host 93.93.93.93
That's all.
What is possible:
- traceroute into MC WAN from Office LAN router "traceroute vrf VRF_MC 55.55.0.83"
1 2.2.2.50 [AS 65276] 8 msec 0 msec 0 msec
2 10.10.21.189 [AS 65276] 4 msec 0 msec 4 msec
3 10.10.41.74 [AS 65276] 12 msec 8 msec 16 msec
- MC LAN is fully reachable from A2A WAN
- Metro link is used for backup and "city" traffic between office and DC.
What does not work:
- A device connected to MC LAN cannot reach any target in MC WAN. Example:
C:\Users\me>tracert -d 55.55.0.83
1     2 ms     1 ms     1 ms 2.2.2.53 <- IP local VLAN31 MC-WAN transfer net (belonging to VRF_MC)
2    <1 ms    <1 ms    <1 ms 2.2.2.18 <- jump back into the GTR (A2A WAN router IP)
3     1 ms     1 ms     1 ms 5.5.5.5 <- A2A WAN
What is missing?? Is my solution itself a no-go?
Additional question: There is a backup metro link with a smaller bandwidth that should be used only in case of main metro link is down. I installed a route-map to "set local-preference 20" for all routes received via this backup metro link. Is this the recommended way to implement such backup link.
Best regards

Use the route map as a noraml thing.
To match the all the ip address there should not be any match statement in the route map.

BGP stuck in opensent state

HELP! Been looking at this problem all day. Have a simple BGP config on my end (below). I have no control on the other end. Recently upgraded from 2811 to 2911. IOS: c2900-universalk9-mz.SPA.151-4.M7.bin Configs on old and new routers exactly the same.
Called our ISP. They see the same debug logs, but have no clue to fix. I can ping across fine. No MTU issues. Move connections back to old 2811 BGP comes up no problem.
interface Serial0/0/0
ip address X.X.X.86 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
service-module t1 fdl ansi
no cdp enable
router bgp 65000
bgp log-neighbor-changes
network Y.Y.Y.0
network Y.Y.Y.16 mask 255.255.255.240
neighbor X.X.X.85 remote-as 2
neighbor X.X.X.85 password 7 06252C1268715E3C5139
debug
Nov 5 11:07:05.493: BGP: Selected new router ID Y.Y.Y.17 for scope global
Nov 5 11:07:05.537: BGP: Applying map to find origin for Y.Y.Y.16/28
Nov 5 11:07:05.541: BGP: Applying map to find origin for Y.Y.Y.16/28
Nov 5 11:07:05.541: BGP: Applying map to find origin for Y.Y.Y.16/28
Nov 5 11:07:05.549: BGP: nbr global X.X.X.85 Active open failed - can't get active topologies
Nov 5 11:07:05.549: BGP: nbr global X.X.X.85 Open active delayed 11264ms (35000ms max, 60% jitter)
Nov 5 11:07:06.457: BGP: X.X.X.85 passive open to X.X.X.86
Nov 5 11:07:06.461: BGP: X.X.X.85 passive went from Idle to Connect
Nov 5 11:07:06.461: BGP: ses global X.X.X.85 (0x307CA074:0) pas Setting open delay timer to 60 seconds.
Nov 5 11:07:06.461: BGP: ses global X.X.X.85 (0x307CA074:0) pas read request no-op
Nov 5 11:07:06.521: BGP: Sched timer-wheel running slow by 8 ticks
Nov 5 11:07:16.761: BGP: X.X.X.85 active went from Idle to Active
Nov 5 11:07:16.761: BGP: X.X.X.85 open active, local address X.X.X.86
Nov 5 11:07:16.773: BGP: ses global X.X.X.85 (0x30B937F4:0) act Adding topology IPv4 Unicast:base
Nov 5 11:07:16.773: BGP: ses global X.X.X.85 (0x30B937F4:0) act Send OPEN
Nov 5 11:07:16.773: BGP: X.X.X.85 active went from Active to OpenSent
Nov 5 11:07:16.773: BGP: X.X.X.85 active sending OPEN, version 4, my as: 65000, holdtime 180 seconds, ID CD464511
Nov 5 11:07:16.785: BGP: X.X.X.85 active rcv message type 3, length (excl. header) 5
Nov 5 11:07:16.785: %BGP-3-NOTIFICATION: received from neighbor X.X.X.85 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
Nov 5 11:07:16.785: BGP: ses global X.X.X.85 (0x30B937F4:0) act Receive NOTIFICATION 2/8 (no supported AFI/SAFI) 3 bytes 000000
Nov 5 11:07:16.785: BGP: ses global X.X.X.85 (0x30B937F4:0) act Reset (BGP Notification received).
Nov 5 11:07:16.785: BGP: X.X.X.85 active went from OpenSent to Closing
Nov 5 11:07:16.785: BGP: nbr_topo global X.X.X.85 IPv4 Unicast:base (0x30B937F4:0) NSF delete stale NSF not active
Nov 5 11:07:16.785: BGP: nbr_topo global X.X.X.85 IPv4 Unicast:base (0x30B937F4:0) NSF no stale paths state is NSF not active
Nov 5 11:07:16.785: BGP: nbr_topo global X.X.X.85 IPv4 Unicast:base (0x30B937F4:0) Resetting ALL counters.
Nov 5 11:07:16.785: BGP: X.X.X.85 active closing
Nov 5 11:07:16.785: BGP: ses global X.X.X.85 (0x30B937F4:0) act Session close and reset neighbor X.X.X.85 topostate
Nov 5 11:07:16.785: BGP: nbr_topo global X.X.X.85 IPv4 Unicast:base (0x30B937F4:0) Resetting ALL counters.
Nov 5 11:07:16.785: BGP: X.X.X.85 active went from Closing to Idle
Nov 5 11:07:16.785: %BGP_SESSION-5-ADJCHANGE: neighbor X.X.X.85 IPv4 Unicast topology base removed from session BGP Notification received
Nov 5 11:07:16.785: BGP: ses global X.X.X.85 (0x30B937F4:0) act Removed topology IPv4 Unicast:base
Nov 5 11:07:16.785: BGP: ses global X.X.X.85 (0x30B937F4:0) act Removed last topology
Nov 5 11:07:16.785: BGP: nbr global X.X.X.85 Active open failed - existing passive session
Nov 5 11:07:16.785: BGP: nbr global X.X.X.85 Active open failed - existing passive session

From what I'm finding, AFI 2 is IPv6. This seems like it's expecting IPv6:
Nov 5 11:07:16.785: %BGP-3-NOTIFICATION: received from neighbor X.X.X.85 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
I'm also seeing that SAFI 8 is multicast:
http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
If this is the case, the settings that you have above simply wouldn't work. I would contact the ISP to see what your peer is running.
http://routing-bits.com/2009/11/26/output-101-bgp-afisafi/
HTH,
John

BGP Best Path Selection Algorithm

How is the administrative distance positioned in the bgp route decision ?
i.e If a route is learned from iBGP with higher "local prefernece" and eBGP with lower "local prefernece" - which path will be installed in the routing table
the path learned from eBGP or the path with higer local prefernce ?

For your scenario the path with the higher local pref will be installed in the routing table althogh its ibgp.
if a router recieves the same prefix from 2 neighbors 1 from ibgp and the other from ebgp
the router will compare them with the bgp path selection algorithm
the one that wins will be installed in the routing table with the admin distance of the kind of route it is so if the ibgp route won the path selection you will see in the routing table the admin distance of 200,if the ebgp route won you'll see 20 in the admin distance.
so remember the ibgp/ebgp comparision is the 9th in the path selection algorithm so an ibgp route can win the path selection by (local pref weight....)
and if the ibgp won then you'll see the ibgp admin dstance in your routing tables.

Weird BGP path selection problem

Hi, all,
I am seeing a weird BGP path selection problem on 4948 switch running cat4500-entservicesk9-mz.122-46.SG.bin code, this switch has two uplinks to the same ISP's different edge router, one circuit is primary the other one is strict backup, only default route is accepted from ISP. I am setting both local preference and weight to the default route advertised over backup link, however neither one is taking effect, BGP still thinks the backup link is better, what could be wrong?
rtr#sh ip bgp 0.0.0.0/0
BGP routing table entry for 0.0.0.0/0, version 105
Paths: (3 available, best #2, table Default-IP-Routing-Table, not advertised to EBGP peer)
Not advertised to any peer
17675, (received & used)
    203.169.8.37 from 203.169.8.37 (61.211.160.150)
      Origin IGP, localpref 100, valid, external
      Community: 65001:0 no-export
17675
    203.169.8.45 from 203.169.8.45 (61.211.160.151)
      Origin IGP, localpref 90, weight 90, valid, external, best <====
      Community: 65001:0 no-export
17675, (received-only)
    203.169.8.45 from 203.169.8.45 (61.211.160.151)
      Origin IGP, localpref 100, valid, external
      Community: 65001:0 no-export
Thanks

Hi,
On cisco routers , weight is having highest preference to decide best path. By default for received route, weight is 0 but you are setting weight 90 to backup path and that is why it is getting preferred (higher is better). Please remove weight and let local preference be 90 (lesser than route on primary path)
--Pls dont forget to rate helpful posts--
Regards,
Akash

BGP Local AS

Similar Messages

Maybe you are looking for