cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2875
Views
0
Helpful
3
Replies

SNMP Polling not working to Mgmt Station

fhoban
Level 1
Level 1

I am having issues getting SNMP polling working from an Arbor device to a cisco GSR. Configuration has been verifed as correct on the arbor box and there is similar working elsewhere in the network. Other snmp management stations can get SNMP info no problem. There is only one hop in between the Arbor mgmt. station  and that is a L2 switch. Cant figure out the problem. I have no access to arbor box currently.Set up as follows.

Arbor CP --> Has 2 interfaces fa2/46 (vlan 98) and fa2/47 (vlan 99) connected to Switch A.

Switch A trunked to Corea A which has dot1q subinterfaces Gi1/1.98 and Gi1/1.99.

Routing etc working fine.

Static ip route to the loopback of the Arbor box redistributed into ospf

Sw A Config;

interface FastEthernet2/46

description *** arbor ***

switchport access vlan 99

switchport mode access

duplex full

speed 100

interface FastEthernet2/47

description *** arbor ***

switchport access vlan 98

switchport mode access

duplex full

speed 100

interface GigabitEthernet3/4

description **Trunk to Core A**

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 97-99

switchport mode trunk

logging event link-status

speed nonegotiate

Core A Config;

interface GigabitEthernet1/1

description

mtu 1600

bandwidth 1000000

no ip address

no ip redirects

no ip directed-broadcast

no ip proxy-arp

load-interval 30

no negotiation auto

  no cdp enable

interface GigabitEthernet1/1.98

description Vlan to eth0.ddos

bandwidth 1000000

encapsulation dot1Q 98

ip address x.x.x.x 255.255.255.252

no ip directed-broadcast

no cdp enable

interface GigabitEthernet1/1.99

description Vlan to eth2

bandwidth 1000000

encapsulation dot1Q 99

ip address x.x.x.x 255.255.255.252

no ip directed-broadcast

no cdp enable

Routing for connectivity to Arbor Loopback

ip route <loopback arbor> 255.255.255.255 <eth0 arbor> tag 9999

ip route <loopback arbor> 255.255.255.255 <eth2 arbor> tag 9999

CoreA-the#sh access-lists 2

Standard IP access list 2 (Compiled)

    50 permit 10.10.10.10  -----------------------------------------> Loopback of Arbor device

    20 permit x.x.x.x(17248 matches)

    10 permit x.x.x.x wildcard bits 0.0.0.31

    30 permit x.x.x.x wildcard bits 0.0.0.63 (419508 matches)

    40 permit x.x.x.x, wildcard bits 0.0.0.255 (1081592 matches)

    60 deny   any log (10248 matches)

route-map DDOS_LOOPBACK, permit, sequence 10

  Match clauses:

    tag 9999

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

router ospf 1

log-adjacency-changes

auto-cost reference-bandwidth 10000

redistribute static metric-type 1 subnets route-map DDOS_LOOPBACK

SNMP CONFIG:

CoreA-the#sh access-lists 2

Standard IP access list 2 (Compiled)

    50 permit 10.10.10.10  -----------------------------------------> Loopback of Arbor device

    20 permit x.x.x.x(17248 matches)

    10 permit x.x.x.x wildcard bits 0.0.0.31

    30 permit x.x.x.x wildcard bits 0.0.0.63 (419508 matches)

    40 permit x.x.x.x, wildcard bits 0.0.0.255 (1081592 matches)

    60 deny   any log (10248 matches)

snmp-server view noroute iso included

snmp-server view noroute ipRouteEntry excluded

snmp-server community xxxxxxxxx view noroute RO 2

Appreciate the help.

3 Replies 3

Hi,

Lets check basic things first.

1. Can you ping Cisco GSR's management's default gateway IP address.

2. Can you ping Cisco GSR's IP address with Arbor's loopback ip address.

I assume, you won't be able to ping in response to point number 2; as if you would have been, then there should not be any problem.

Regards,

Smitesh

Thanks for reply Smitesh. Pings work fine although the arbor doesnt give an option to specify loopback. TCP Dump from arbor box below.

Source now set to loopback.

Going out to

Using snmp port 161

SNMP community looks ok

BUT

No response and no hits on access list 2

SEE dump below.

Internet Protocol, Src: X.XX.X, Dst: X.X.X.X Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 78

Identification: 0x0000 (0)

Flags: 0x04 (Don't Fragment)

0... = Reserved bit: Not set

.1.. = Don't fragment: Set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 64

Protocol: UDP (0x11)

Header checksum: 0x16f2 [correct]

[Good: True]

[Bad : False]

Source: X.X.X.X

Destination: X.X.X.X

User Datagram Protocol, Src Port: 14650 (14650), Dst Port: snmp (161)

Source port: 14650 (14650)

Destination port: snmp (161)

Length: 58

Checksum: 0x9204 [correct]

[Good Checksum: True]

[Bad Checksum: False]

Simple Network Management Protocol

version: v2c (1)

community: XXXXXXXXXXXXXXX

data: getBulkRequest (5)

getBulkRequest

request-id: 953983092

non-repeaters: 0

max-repetitions: 2

variable-bindings: 1 item

Item

name: 1.3.6.1.4.1.9.9.109.1.1.1.1.5

valueType: unSpecified (1)

unSpecified

Smitesh, It was an ACL configured on the GSR under global config ' ip receive-list xxxx'. Never saw this command before and given  the size of the config file never spotted it.

Thanks for your input !